Modelling Computer Based Business Process For Customisation And Delivery

ABSTRACT

A modelling system to provide a computer based business process for an enterprise, allows the enterprise to input values for a plurality of non functional requirements ( 760 ) for the deployment, and allows at least some of the values to be varied independently of others of the values, and creates a design of software application components ( 770 ) and a design of computing infrastructure ( 780 ), for running the software application components, so that the business process operates according to the values input for the non functional requirements of the business process. By modelling the underlying computing infrastructure, it becomes feasible to create models with greater certainty that they will deploy successfully, and with greater predictability of how well they will meet given non functional requirements. This enables more freedom to be allowed to vary the values of these non functional requirements and get greater customisation to suit the needs of the enterprise.

RELATED APPLICATIONS

This application relates to copending US applications of even datetitled “MODEL BASED DEPLOYMENT OF COMPUTER BASED BUSINESS PROCESS ONDEDICATED HARDWARE” (applicant reference number 200702144), titled“VISUAL INTERFACE FOR SYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ONSHARED INFRASTRUCTURE” (applicant reference number 200702356), titled“MODELLING COMPUTER BASED BUSINESS PROCESS FOR CUSTOMISATION ANDDELIVERY” (applicant reference number 200702145), titled “SETTING UPDEVELOPMENT ENVIRONMENT FOR COMPUTER BASED BUSINESS PROCESS” (applicantreference number 200702377), titled “AUTOMATED MODEL GENERATION FORCOMPUTER BASED BUSINESS PROCESS”, (applicant reference number200702600), and titled “INCORPORATING DEVELOPMENT TOOLS IN SYSTEM FORDEPLOYING COMPUTER BASED PROCESS ON SHARED INFRASTRUCTURE”, (applicantreference number 200702601), and previously filed US application titled“DERIVING GROUNDED MODEL OF BUSINESS PROCESS SUITABLE FOR AUTOMATICDEPLOYMENT” (Ser. No. 11/741,878) all of which are hereby incorporatedby reference in their entirety.

FIELD OF THE INVENTION

The invention relates to methods of using a modelling system to providea computer based business process for an enterprise, so as to enable atleast partially automated deployment of the business process and tocorresponding systems and software.

BACKGROUND

Physical IT (information technology) infrastructures are difficult tomanage. Changing the network configuration, adding a new machine orstorage device are typically difficult manual tasks. In most physical ITinfrastructure, resource utilization is very low: 15% is not an uncommonutilization for a server, 5% for a desktop. To address this, moderncomputer infrastructures are becoming increasingly (re)-configurable andmore use is made of shared infrastructure in the form of data centresprovided by service providers.

Hewlett Packard's UDC (Utility Data Centre) is an example which has beenapplied commercially and allows automatic reconfiguration of physicalinfrastructure: processing machines such as servers, storage devicessuch as disks, and networks coupling the parts. Reconfiguration caninvolve moving or starting software applications, changing allocationsof storage space, or changing allocation of processing time to differentprocesses for example. Another way of contributing morereconfigurability, is by allowing many “virtual” computers to be hostedon a single physical machine. The term “virtual” usually means theopposite of real or physical, and is used where there is a level ofindirection, or some mediation between the resource user and thephysical resource.

In addition some computing fabrics allow the underlying hardware to bereconfigured. In once instance the fabric might be configured to providea number of four-way computers. In another instance it might bere-configured to provide four times as many single processor computers.

It is extremely complex to model the full reconfigurability of theabove. Models of higher level entities need to be recursive in the senseof containing or referring to lower level entities used or required toimplement them (for example a virtual machine VM, may operate faster orslower depending on what underlying infrastructure is currently used toimplement it (for example hardware partition nPAR or virtual partitionvPAR, as will be described in more detail below). This means a modelneeds to expose the underlying configurability of the next generationcomputer fabrics—an nPAR consists of a particular hardware partition.This makes the models so complex that it becomes increasingly difficultfor automated tools (and humans) to understand and process the models,to enable design and management of: a) the business process, b) theapplication and application configuration, and c) the infrastructure andinfrastructure configuration.

The need to model the full reconfigurability and recursive nature of asystem is exemplified in the DMTF's profile for “System Virtualization,Partitioning and Clustering”:http://www.dmtf.org/apps/org/workgroup/redundancy/

Another example of difficulties in modelling is WO2004090684 whichrelates to modeling systems in order to perform processing functions. Itsays “The potentially large number of components may render the approachimpractical. For example, an IT system with all of its hardwarecomponents, hosts, switches, routers, desktops, operating systems,applications, business processes, etc. may include millions of objects.It may be difficult to employ any manual or automated method to create amonolithic model of such a large number of components and theirrelationships. This problem is compounded by the typical dynamic natureof IT systems having frequent adds/moves/changes. Secondly, there is noabstraction or hiding of details, to allow a processing function tofocus on the details of a particular set of relevant components whilehiding less relevant component details. Thirdly, it may be impracticalto perform any processing on the overall system because of the number ofcomponents involved.”

There have been attempts to automatically and rapidly provide computinginfrastructures: HP's Utility Data Center, HP Lab's SoftUDC, HP's Caveoand Amazon's Elastic Compute Cloud (which can be seen athttp://www.amazon.com/gp/browse.html?node=201590011). All of theseprovide computing infrastructures of one form or another, and some havebeen targeted at testers and developers, e.g. HP's Utility Data Center.

Aris from IDS-Scheer is a known business process modelling platformhaving a model repository containing information on the structure andintended behaviour of the system. In particular, the business processesare modelled in detail. It is intended to tie together all aspects ofsystem implementation and documentation. Aris UML designer is acomponent of the Aris platform, which combines conventional businessprocess modelling with software development to develop businessapplications from process analysis to system design. Users accessprocess model data and UML content via a Web browser, thereby enablingprocessing and change management within a multi-user environment. It canprovide for creation and communication of development documentation, andcan link object-oriented design and code generation (CASE tools). Itdoes not model computing infrastructure of the shared infrastructure ina datacentre nor provide a high level interface for enterprises to orderthe delivery of a service.

Utility computing interfaces today fall into a number of categories, forexample:

1. The “pile of machines”: The customer is handed dozens or hundreds ofmachines, which they need to manage. The problem here is that it takes alot of time and money to manage these machines, and it is not thecustomer's core competency.2. The “single application provider”: Customers can gain access tomanaged applications from ASPs (application service providers). In thisway, they don't need to manage machines nor applications. The problemhere is that the application is not integrated with the customer's otherapplications, resulting in significantly lower value to the customer.Integration can be done, but it is usually expensive, long, andcustomized. It is quite difficult to change the business process whichuses this and other applications because the ASP typically has a limitedrange of choices. Proprietary business process which allow the customercompetitive advantage are either disallowed, or expensive and lengthy toimplement and difficult to change.3. The “application suite”: An example is Salesforce.com which has arelatively advanced utility computing interfaces for customers, whichavoids many of the problems listed above. The choice of services andapplications is still rather small, but will grow over time. However,customizations to the business processes and their non-functionalrequirements will still be limited to the set of choices offered, whichwill likely remain rather small compared to the range of requirements ofdifferent enterprises.

SUMMARY OF THE INVENTION

An object is to provide improved apparatus or methods. In one aspect theinvention provides:

A method of using a modelling system to provide a computer basedbusiness process for an enterprise, so as to enable at least partiallyautomated deployment of the business process, the business processhaving a number of functional steps, the method having the steps of:

a) allowing the enterprise to input to the modelling system values for aplurality of non functional requirements for the deployment, so as toprovide freedom for the enterprise to vary at least some of the valuesindependently of others of the values, andb) using the modelling system to create the model using the valuesinput, by:c) creating in the model a design of software application components forcarrying out the functional steps, andd) creating in the model a design of computing infrastructure, forrunning the software application components, so that the businessprocess deployed as set out in the model, operates according to thevalues input for the non functional requirements of the businessprocess.

By modelling not only the software for carrying out the functionalsteps, but also the underlying computing infrastructure, it becomesfeasible to create models with greater certainty that they will deploysuccessfully, and with greater predictability of how well they will meetgiven non functional requirements. This enables more freedom to beallowed to enterprises to vary the values of these non functionalrequirements independently of one another. This enables greatercustomisation to suit the needs of the enterprise which is veryattractive to the enterprise, and so enables the service provider toattract more business. At the same time, the service provider canbenefit from more efficient allocation of shared resources and thusoffer services at lower costs. Previously providing such flexibilitywould have needed expensive manual customisation.

Embodiments of the invention can have any additional features, withoutdeparting from the scope of the claims, and some such additionalfeatures are set out in dependent claims and in embodiments describedbelow.

Another aspect provides software on a machine readable medium which whenexecuted carries out the above method.

Another aspect provides a modelling system to provide a computer basedbusiness process for an enterprise, so as to enable at least partiallyautomated deployment of the business process, the business processhaving a number of functional steps, the system having:

a) an interface to allow the enterprise to input values for a pluralityof non functional requirements for the deployment, so as to providefreedom for the enterprise to vary at least some of the valuesindependently of others of the values, andb) a model generating part coupled to the interface and arranged tocreate the model using the values input, by:c) creating in the model a design of software application components forcarrying out the functional steps, andd) creating in the model a design of computing infrastructure, forrunning the software application components, so that the businessprocess deployed as set out in the model, operates according to thevalues input for the non functional requirements of the businessprocess.

Other aspects can encompass corresponding steps by human operators usingthe system, to enable direct infringement or inducing of directinfringement in cases where the infringer's system is partly or largelylocated remotely and outside the jurisdiction covered by the patent, asis feasible with many such systems, yet the human operator is using thesystem and gaining the benefit, from within the jurisdiction. Otheradvantages will be apparent to those skilled in the art, particularlyover other prior art. Any of the additional features can be combinedtogether, and combined with any of the aspects, as would be apparent tothose skilled in the art. The embodiments are examples only, the scopeis not limited by these examples, and many other examples can beconceived within the scope of the claims.

BRIEF DESCRIPTION OF THE FIGURES

Specific embodiments of the invention will now be described, by way ofexample, with reference to the accompanying Figures, in which:

FIG. 1 shows a schematic view of an embodiment showing models, adaptiveinfrastructure and a management system,

FIG. 2 shows a schematic view of some operation steps by an operator andby the management system, according to an embodiment,

FIG. 3 shows a schematic view of some of the principal actions andmodels according to an embodiment,

FIG. 4 shows a schematic view of a sequence of steps from businessprocess to deployed model in the form of a model information flow, MIF,according to another embodiment,

FIG. 5 shows a sequence of steps and models according to anotherembodiment,

FIG. 6 shows steps in deriving a grounded model according to anembodiment,

FIG. 7 shows an arrangement of master and slave application servers fora distributed design, according to an embodiment,

FIG. 8 shows parts of a master application server for the embodiment ofFIG. 7,

FIG. 9 shows an arrangement of virtual entities on a server, for use inan embodiment,

FIG. 10 shows an example of a sales and distribution business process(SD) Benchmark Dialog Steps and Transactions,

FIG. 11 shows an example Custom Model Instance for SD Benchmark,

FIG. 12 shows a class diagram for an Unbound Model Class,

FIG. 13 shows an example of a template suitable for a decentralised SDexample,

FIG. 14 shows a Grounded Model instance for a decentralized SD,

FIG. 15 shows another example of a template, suitable for a centralisedsecure SD example,

FIG. 16 shows an overview of an embodiment of a system,

FIG. 17 shows a method according to another embodiment,

FIG. 18 shows a method according to another embodiment,

FIGS. 19 and 20 show a system and method according to an embodiment,

FIGS. 21, and 22 show a system and method steps according to anotherembodiment,

FIGS. 23 and 24 show a system and method according to a furtherembodiment, and

FIG. 25 shows method steps according to another embodiment.

DESCRIPTION OF SPECIFIC EMBODIMENTS Definitions

“non-functional requirements” can be regarded as how well the functionalsteps are achieved, in terms such as performance, security properties,cost, availability and others. It is explained in Wikipedia(http://en.wikipedia.org/wiki/Non-functional_requirements) fornon-functional requirements as follows—“In systems engineering andrequirements engineering, non-functional requirements are requirementswhich specify criteria that can be used to judge the operation of asystem, rather than specific behaviors. This should be contrasted withfunctional requirements that specify specific behavior or functions.Typical non-functional requirements are reliability, scalability, andcost. Non-functional requirements are often called the ilities of asystem. Other terms for non-functional requirements are “constraints”,“quality attributes” and “quality of service requirements”.”

Functional steps can encompass any type of function of the businessprocess, for any purpose, such as interacting with an operator receivinginputs, retrieving stored data, processing data, passing data orcommands to other entities, and so on, typically but not necessarily,expressed in human readable form . . . .

“Deployed” is intended to encompass a modelled business process forwhich the computing infrastructure has been allocated and configured,and the software application components have been installed andconfigured ready to become operational. According to the context it canalso encompass a business process which has started running.

“suitable for automated deployment” can encompass models which providemachine readable information to enable the infrastructure design to bedeployed, and to enable the software application components to beinstalled and configured by a deployment service, either autonomously orwith some human input guided by the deployment service.

“business process” is intended to encompass any process involvingcomputer implemented steps and optionally other steps such as humaninput or input from a sensor or monitor for example, for any type ofbusiness purpose such as service oriented applications, for sales anddistribution, inventory control, control or scheduling of manufacturingprocesses for example. It can also encompass any other process involvingcomputer implemented steps for non business applications such aseducational tools, entertainment applications, scientific applications,any type of information processing including batch processing, gridcomputing, and so on. One or more business process steps can be combinedin sequences, loops, recursions, and branches to form a completeBusiness Process. Business process can also encompass businessadministration processes such as CRM, sales support, inventorymanagement, budgeting, production scheduling and so on, and any otherprocess for commercial or scientific purposes such as modelling climate,modelling structures, or modelling nuclear reactions.

“application components” is intended to encompass any type of softwareelement such as modules, subroutines, code of any amount usableindividually or in combinations to implement the computer implementedsteps of the business process. It can be data or code that can bemanipulated to deliver a business process step (BPStep) such as atransaction or a database table. The Sales and Distribution (SD) productproduced by SAP is made up of a number of transactions each having anumber of application components for example.

“unbound model” is intended to encompass software specifying in any way,directly or indirectly, at least the application components to be usedfor each of the computer implemented steps of the business process,without a complete design of the computing infrastructure, and mayoptionally be used to calculate infrastructure resource demands of thebusiness process, and may optionally be spread across or consist of twoor more sub-models. The unbound model can also specify the types orversions of corresponding execution components such as applicationservers and database servers, needed by each application component,without specifying how many of these are needed for example.

“grounded model” is intended to encompass software specifying in anyway, directly or indirectly, at least a complete design of the computinginfrastructure suitable for automatic deployment of the businessprocess. It can be a complete specification of a computinginfrastructure and the application components to be deployed on theinfrastructure.

“bound model” encompasses any model having a binding of the GroundedModel to physical resources. The binding can be in the form ofassociations between ComputerSystems, Disks, StorageSystems, Networks,NICS that are in the Grounded Model to real physical parts that areavailable in the actual computing infrastructure.

“infrastructure design template” is intended to encompass software ofany type which determines design choices by indicating in any way atleast some parts of the computing infrastructure, and indicatingpredetermined relationships between the parts. This will leave a limitednumber of options to be completed, to create a grounded model. Thesetemplates can indicate an allowable range of choices or an allowablerange of changes for example. They can determine design choices byhaving instructions for how to create the grounded model, or how tochange an existing grounded model.

“computing infrastructure” is intended to encompass any type of resourcesuch as hardware and software for processing, for storage such as disksor chip memory, and for communications such as networking, and includingfor example servers, operating systems, virtual entities, and managementinfrastructure such as monitors, for monitoring hardware, software andapplications. All of these can be “designed” in the sense of configuringand/or allocating resources such as processing time or processorhardware configuration or operating system configuration or disk space,and instantiating software or links between the various resources forexample. The resources may or may not be shared between multiplebusiness processes. The configuring or allocating of resources can alsoencompass changing existing configurations or allocations of resources.Computing infrastructure can encompass all physical entities or allvirtualized entities, or a mixture of virtualized entities, physicalentities for hosting the virtualized entities and physical entities forrunning the software application components without a virtualized layer.

“parts of the computing infrastructure” is intended to encompass partssuch as servers, disks, networking hardware and software for example.

“server” can mean a hardware processor for running application softwaresuch as services available to external clients, or a software elementforming a virtual server able to be hosted by a hosting entity such asanother server, and ultimately hosted by a hardware processor.

“AIService” is an information service that users consume. It implementsa business process.

“Application Constraints Model” can mean arbitrary constraints oncomponents in the Customized Process, Application Packaging andComponent Performance Models. These constraints can be used by tools togenerate additional models as the MIF progresses from left to right.

“ApplicationExecutionComponent” is for example a (worker) process,thread or servlet that executes an Application component. An examplewould be a Dialog Work Process, as provided by SAP.

“ApplicationExecutionService” means a service which can manage theexecution of ApplicationExecutionComponents such as Work Processes,servlets or database processes. An example would be an ApplicationServer as provided by SAP. Such an application server includes thecollection of dialog work processes and other processes such as updateand enqueue processes as shown in the diagram of the master applicationserver. (FIG. 8).

“Application Packaging Model” is any model which describes the internalstructure of the software: what products are needed and what modules arerequired from the product, and is typically contained by an unboundmodel.

“Application Performance Model” means any model which has the purpose ofdefining the resource demands, direct and indirect, for each businessprocess (BP) step. It can be contained in the unbound model.

“Component Performance Model” can mean any model containing the genericperformance characteristics for an Application Component. This can beused to derive the Application Performance Model (which can be containedin the unbound model), by using the specific business process steps anddata characteristics specified in the Custom Model together withconstraints specified in the Application Constraints Model.

“Custom Model” means a customized general model of a business process toreflect specific business requirements.

“Deployed Model” means a bound model with the binding information forthe management services running in the system.

“Candidate Grounded Model” can be an intermediate model that may begenerated by a tool as it transforms the Unbound Model into the GroundedModel.

“Grounded Component” can contain the installation and configurationinformation for both Grounded Execution Components and GroundedExecution Services, as well as information about policies and start/stopdependencies.

“Grounded Execution Component” can be a representation in the GroundedModel of a (worker) process, thread or servlet that executes anApplication Component.

“Grounded Execution Service” is a representation in the Grounded Modelof the entity that manages the execution of execution components such asWork Processes, servlets or database processes.

“Infrastructure Capability Model” can be a catalogue of resources thatcan be configured by the utility such as different computer types anddevices such as firewalls and load balancers.

MIF (Model Information Flow) is a collection of models used to manage abusiness process through its entire lifecycle.

The present invention can be applied to many areas, the embodimentsdescribed in detail can only cover some of those areas. It can encompassmodeling dynamic or static systems, such as enterprise managementsystems, networked information technology systems, utility computingsystems, systems for managing complex systems such as telecommunicationsnetworks, cellular networks, electric power grids, biological systems,medical systems, weather forecasting systems, financial analysissystems, search engines, and so on. The details modelled will generallydepend on the use or purpose of the model. So a model of a computersystem may represent components such as servers, processors, memory,network links, disks, each of which has associated attributes such asprocessor speed, storage capacity, disk response time and so on.Relationships between components, such as containment, connectivity, andso on can also be represented.

An object-oriented paradigm can be used, in which the system componentsare modeled using objects, and relationships between components of thesystem are modeled either as attributes of an object, or objectsthemselves. Other paradigms can be used, in which the model focuses onwhat the system does rather than how it operates, or describes how thesystem operates. A database paradigm may specify entities andrelationships. Formal languages for system modelling include text basedDMTF Common InformationModel (CIM), Varilog, NS, C++, C, SQL, orgraphically expressed based schemes.

Additional Features

Some examples of additional features for dependent claims are asfollows:

The input values can be changes to values of non functional requirementsfor an existing deployment, and creating the model can comprise makingchanges to an existing model. In practice, modifying the requirements isoften needed and is difficult and risky for complex systems andtherefore the above advantages are more valuable for such changes.

The method can have the step of deploying the model to operate thebusiness process. Deploying can be made more predictable and reliablesince the model has not only the software for carrying out thefunctional steps, but also the underlying computing infrastructure.

The model can be used to simulate operation, and determine how well thesimulated operation accords to the non functional requirements. This canhelp in evaluating designs to find a better or optimal solution morequickly.

There can be a step of making available to the enterprise an indicationof how well the simulated operation accords to the non functionalrequirements. This can help enable the enterprise to refine theirrequirements more quickly in an iterative way, especially where thereare trade offs between different requirements.

There can be steps of monitoring the operation of the deployed businessprocess, and of making available to the enterprise an indication of howwell the operation accords to the non functional requirements based onthe monitoring. This can help in ensuring the non functionalrequirements continue to be satisfied as conditions change over time.

The design of computing infrastructure can be an output, the designcomprising virtual infrastructure, without a complete mapping tophysical infrastructure, for later deployment by mapping onto physicalinfrastructure. The virtualisation can provide more granularity whichcontributes to flexibility, which complements the advantages set outabove for the enterprise and the service provider. The design can befurther processed or deployed by another party or at another location.

The method can have the step of outputting the design of computinginfrastructure, the design comprising physical infrastructure withoutvirtualisation. This helps avoid the additional cost, complexity andperformance loss of virtualisation, which are significant for certaintypes of application.

The method can have the step of outputting the design of computinginfrastructure, the design comprising both virtual and physicalinfrastructure, and a mapping of the virtual infrastructure ontocorresponding physical infrastructure. This is common practice and soserves a large part of the market currently.

The step of creating in the model an arrangement of software applicationcomponents can comprise creating an unbound model with a representationof software application performance, and software application packaging.This is a convenient way to implement such a step efficiently.

The step of creating in the model a design of computing infrastructurecan comprise creating a grounded model from the unbound model, with arepresentation of infrastructure design and infrastructure capability.This is a convenient way to implement this part more efficiently.

The step of creating the design of computing infrastructure can compriseproviding an infrastructure design template having a limited number ofoptions to be completed. This can help simplify the task and increasecertainty and reliability of a successful deployment.

It is possible for the service provider to deploy on dedicated hardwarelocal to the enterprise, and provide the benefits of management by aservice provider. Reference is made to above referenced copendingapplication number 200702144 for more details of examples of this.Combining this with the enterprise interface provided to enable theenterprise to customise the non functional requirements independently ofeach other, can further enhance the customisation.

Where a 3-D visual interface is provided with a game server to enablemultiple developers to work on the same model and see each others'changes, developers can navigate complex models more quickly. Referenceis made to above referenced copending application number 200702356 formore details of examples of this.

Combining this with the enterprise interface provided to enable theenterprise to customise the non functional requirements independently ofeach other, can enable the advantages of both to be enhanced.

Where the operation of the business process can be simulated or wheremultiple test deployments can be made in parallel, development can beaccelerated. Reference is made to above referenced copending applicationnumber 200702377 for more details of examples of this. Combining thiswith the enterprise interface provided to enable the enterprise tocustomise the non functional requirements independently of each other,can enable the advantages of both to be enhanced.

It is possible to use annotations inserted in the source code to assistin modelling or in documentation. Reference is made to above referencedcopending application number 200702600 for more details of examples ofthis. Combining this with the enterprise interface provided to enablethe enterprise to customise the non functional requirementsindependently of each other, can enable the advantages of both to beenhanced.

Setting up of a development environment can be facilitated by providinga predetermined mapping of which tools are appropriate for a givendevelopment purpose and given part of the model, or by including modelsof tools to be deployed with the model. Reference is made to abovereferenced copending application numbers 200702145, and 200702601 formore details of examples of this. As enabling the enterprise tocustomise the non functional requirements independently of each othercan make the development work more demanding, it can become all the morevaluable to facilitate setting up the development environment.

Model Based Approach

A general aim of this model based approach is to enable development andmanagement to provide matched changes to three main layers: thefunctional steps of the process, the applications used to implement thefunctional steps of the process, and configuration of the computinginfrastructure used by the applications. Such changes are to be carriedout automatically by use of appropriate software tools interacting withsoftware models modelling the above mentioned parts. Until now there hasnot been any attempt to link together tools that integrate businessprocess, application and infrastructure management through the entiresystem lifecycle.

A model-based approach for management of such complex computer basedprocesses will be described. Such models can have structured data modelsin CIM/UML to model the following three layers:

-   -   Infrastructure elements, such as physical machines, VMs,        operating systems, network links.    -   Application elements, such as Databases, application servers.    -   Business level elements, such as functional steps of business        processes running in the application servers.

A model is an organized collection of elements modelled in UML forexample. A goal of some embodiments is to use these data models for theautomated on-demand provision of enterprise applications following aSoftware as a service (SaaS) paradigm.

Problem Statement

The design of the hardware infrastructure and software landscape forlarge business processes such as enterprise applications is an extremelycomplex task, requiring human experts to design the software andhardware landscape. Once the enterprise application has been deployed,there is an ongoing requirement to modify the hardware and softwarelandscape in response to changing workloads and requirements. Thismanual design task is costly, time-consuming, error-prone, andunresponsive to fast-changing workloads, functional requirements, andnon-functional requirements. The embodiments describe mechanisms toautomatically create an optimised design for an enterprise application,monitor the running deployed system, and dynamically modify the designto best meet the non-functional requirements input via a high-levelenterprise interface. This interface to utility computing servicesprovided by a service provider can also be used for other enterpriserequirements including functional steps of the business processes andassociated service level agreements.

The enterprise interface helps enable the enterprise to focus onrequesting what they want more precisely, and leave the utility serviceprovider to determine how to provide it efficiently. The enterprise canspecify:

-   -   1. the business processes they need provided, such as for        example a CRM (Customer Relationship Management) System, a Sales        and Distribution System, and an Inventory System.    -   2. the non-functional requirements of those business processes,        such as specific levels of performance, security, and        availability, and optionally    -   3. a service level agreement covering the provided services,        such as monetary penalties for not meeting specific functional        or non-functional requirements

Up to now, enterprises cannot specify individual values for differentrequirements to fit what they want from an automated deployment of a setof complex business processes. They typically also specify a greatamount of detail about how the service should be provided, for example,which software and hardware should be used to deliver the service, whatsecurity devices need to be in place, or where the physicalinfrastructure will be placed. This means that much input is needed fromknowledgeable experts. Often expensive and lengthy consultingengagements are required to refine the business processes, theirsupporting applications, and the applications' supporting ITinfrastructure. Enabling the enterprise to specify what they wantwithout worrying about how it is delivered saves time and money. Doingthis at a high level (the business process level) saves more time andmoney compared to, for example, doing it at the application level (whichwould mean that the enterprise would need to spend the time and effortto map their business processes onto a set of supporting applicationsand determine the details of how to couple those applications). Enablingthe ability to specify non-functional requirements for the businessprocesses like performance, security, and availability, enables thecustomer to actually specify in complete form everything they needwithout specifying how it gets delivered. Finally, including SLAs(service level agreements) at this business process level allows theutility services provider to operate and manage the complete solution onthe behalf of the enterprise and to their satisfaction.

Providing this level of utility services offerings can allow enterprisesto reap the rewards of integrated IT applications implementing complexbusiness processes with fewer, or no, IT staff on their payroll. It willalso allow smaller enterprises to take advantage of the large scale ofthe utility services provider's operation. This also helps solve theproblem of the utility services provider having difficulty attractingcustomers to their service offerings because it provides for a veryflexible and high-level service offering that many customers will findvaluable (because they save time and money).

This can also solve the problem for enterprises today of them beingunable to specify how relatively valuable certain levels of performance,security, availability, reliability, etc. are to them and obtainmeaningful and useful service options from the utility servicesprovider. It allows the utility services provider, for the first time,to optimize their service offering based upon the value to each specificenterprise of certain levels of performance, security, availability,reliability, etc. to match their specific needs. This can help providethe maximal value to the enterprise for their money, which is notpossible with today's utility service interfaces.

Design Process

There are two basic inputs to the design process:

-   -   Specification of functional requirements. Typically, this is in        the form of a set of Business steps that the application is to        support. These describe what the system is intended to do from        the perspective of end users. The specification will specify the        set of standard business steps required from a standard        catalogue, and any system-specific customisations of these        steps. This specification will determine the set of products and        optional components that must be included in the design of a        suitable software landscape for the enterprise application.    -   Specification of non-functional requirements. This defines the        requirements that the design must meet, such as performance,        security, reliability, cost, and maintainability. Examples of        performance could include the total and concurrent number of        users to be supported, transaction throughput, or response        times.

The design process involves the creation of a specification of thehardware and software landscape of the enterprise application that willmeet the functional and non-functional requirements described above.This consists of:

-   -   A set of physical hardware resources, selected from an available        pool. The infrastructure would consist of computers, memory,        disks, networks, storage, and appliances such as firewalls.    -   Optionally, a virtual infrastructure to be deployed onto the        physical resources, together with an assigned mapping of virtual        infrastructure to physical infrastructure. The virtual        infrastructure should be configured in such a way to best take        advantage of the physical infrastructure and support the        requirements of the software running on it. For example, the        amount of virtual memory or priority assigned to a virtual        machine.    -   A selection of appropriately configured software components and        services, distributed across the virtual and physical        infrastructure. The software must be configured to meet the        system specific functional requirements, such as customisations        of standard business processes. Configuration parameters could        include the level of threading in a database, the set of        internal processes started in an application server, or the        amount of memory reserved for use by various internal operations        of an application server.

A design for the Enterprise application consists of:

-   -   Selection of appropriate topological layouts, quantities and        types of physical and virtual infrastructure and software        components    -   Configuration parameters for the infrastructure and software        components and services.

The embodiments described below are concerned with an automatedmechanism to create an optimised design for an enterprise application bymodelling the enterprise application in order to simulate the effect ofvarious design parameters, such that the most appropriate selections andconfigurations can be made. A model manager in the form of a Model-BasedDesign Service (MBDS) is responsible for the creation of a set of modelsof the system, each with slightly different parameters for selection,configuration, and evaluation possibilities. The design process can besimply regarded as a search for and selection of the best model, usuallyin terms of finding the least expensive model which meets the functionaland non-functional requirements of the system.

FIGS. 16 to 18, Embodiments of the Invention.

FIG. 16 shows an overview of some principal parts of a system accordingto an embodiment, for deployment of a business process, the systemhaving an enterprise interface 795. The enterprise uses the interface tospecify to a service provider the desired business process or processeswith non-functional requirements and optionally also service levelagreements.

A model generation part 725 is used to generate a corresponding model,stored in store 735, which can then be deployed by deployment part 745.The deployed business process 765 can be managed by management services755. As shown in FIG. 17, an example of steps of the system of FIG. 16in operation starts with receiving the inputs from the enterprise atstep 702. This can include non functional requirements, individuallyspecified, and other items such as functional steps of the businessprocess (or a choice of predetermined steps from a catalog for example),and the service level agreement if needed. At step 712 a model ofsoftware application components to implement the functional steps isgenerated by the model generation part. This can be implemented invarious ways, and an example is described in more detail with referenceto FIGS. 1 to 15 below.

At step 722, a model of computing infrastructure for use in running thesoftware application components is generated. This can be physicalinfrastructure, virtualised infrastructure, or commonly a mixture ofboth, some of the physical infrastructure for running the components andsome for hosting the virtualised infrastructure. All is designed to meetthe non functional requirements. The design may be semi automated in thesense of having an operator make decisions but being prompted and guidedby design service software, such as the design template approachdescribed in more detail below. At step 732 the model is deployed onphysical infrastructure, and ongoing management of the deployed processcan be provided at step 742.

FIG. 18 shows an example. At step 704, the enterprise uses the interfaceto specify a type of system such as CRM, or combination CRM, Salesmodule, inventory management. At step 714, the enterprise specifies astructure of transactions for each system, such as CRM transaction typesA, B, C, H, in any order. Then at step 724 the functional steps of eachtransaction type are specified by the enterprise, such as

-   -   A: manage customer record (display, create modify or delete)    -   B: add or delete lead to customer record    -   C: add or delete opportunity to customer record    -   H: search customer record by keyword

Then at step 734, the enterprise enters non functional requirements forperformance, such as average response time less than 2 seconds, and 95%of requests within 5 seconds, up to 100 users concurrently daytime, 10users nighttime, and so on. Next the enterprise enters non functionalrequirements for availability, such as 99%, 365 days per year with 2 hrmaintenance every weekend at step 744. The enterprise enters nonfunctional requirements for security at step 754, such as requiring thatall data at rest must be stored in encrypted format using the AES-256encryption algorithm. The enterprise can in some cases specify somedetails of underlying software applications, if for example theenterprise has preferred or authorised types or suppliers for suchsoftware, or can leave that entirely to the service provider.

Another example can be as follows:

-   -   Enterprise enters a requirement for a CRM system, capable of        handling 100 users at the start, and capable of scaling up to        10000 users within 3 years. The CRM system must support        transaction types A, B, C, E, and H:    -   A. Manage customer record (display, create, modify, delete)    -   B. Add/delete lead to customer record    -   C. Add/delete opportunity to customer record    -   E. Add/delete notes to customer record    -   H. Search customer records on keywords    -   Performance requirements for non-search requests: Average        response time must be less than 2 seconds, and 95% of requests        must complete within 5 seconds, for requests of size 50 Kb or        less, when all users are actively using the system.    -   Performance requirements for search requests: Average response        time must be less than 4 seconds, and 95% of requests must        complete within 10 seconds, for requests of size 10 Kb or less,        with results of size 50 Kb or less, when all users are actively        using the system with search queries.    -   Availability requirements: The service should be available at        the stated level of performance 99.5% of the time, 24 hrs per        day, 7 days per week, 365 days per year. Two scheduled        maintenance windows of 2 hours each are permitted per month, on        Saturdays. One maintenance window of 24 hours is permitted once        per year, the precise date to be mutually agreed upon in        writing.    -   Security requirements: The service will accept requests only        from three of our company's proxy servers. In addition, since        this system handles sensitive data, the service provider must        install, maintain, and monitor an Intrusion Prevention System        from our approved vendor list: vendor A, vendor B, and vendor C.    -   Reliability requirements: If the service or a piece of the        service crashes, the service must be restored to full        performance operation within 24 hours.

From this information, a machine-interpretable model is created usingone or more of the many modelling languages and tools available, and/ornew tools specific to this purpose. The machine-interpretable model caninclude the steps required to execute each business process listedabove, so that performance, availability, and security characteristicscan be understood and modelled, allowing the service provider to sizeand deploy the systems including security devices, performance deviceslike load balancers, etc. The machine-interpretable model is used toselect and configure the set of software and hardware needed to deliverthe business processes with the specified performance, security, andavailability characteristics. The hardware and software can beautomatically deployed using deployment engines. Alternately, thesoftware and hardware can be manually deployed by humans, or somecombination of manual and automated deployment may be used.

A comparative example now follows. Service providers must strike abalance between providing a variety of choices of service offerings forthe enterprises they serve and being able to feasibly and profitablydeliver those chosen service offerings. A common way that serviceproviders bundle their service offerings today to strike this balance isto offer a few tiered levels of service, such as “gold, silver, andbronze” service levels. The enterprise picks the closest fit to theirneeds, which often isn't very close to what they want. The gold servicelevel typically has the highest levels of performance, availability, andsecurity; the silver service level slightly lower levels of each; andthe bronze service level the lowest levels of each. A simplified examplefollows:

TABLE 1 according to known practice Performance Availability SecurityAverage Overall Service Intrusion Service Maximum response servicerecovery Data Detection Level number of users time availability timeencryption System Gold 1000 2 seconds 99.99%  2 hours AES-512 includedSilver 500 3 seconds 99.95% 24 hours AES-256 none Bronze 100 3 seconds 99.9% 48 hours AES-128 none

The combination of the high level enterprise interface, the collectionof models and the automated deployment engines make it feasible for theservice provider to offer the enterprise the capability to independentlyadjust these inputs for various performance, availability, security, andother non-functional requirements (NFRs) of the service, in some casesfar beyond the choices represented in the 6 columns above. Thus, in thisexample, the enterprise doesn't need to pay for the higher level ofavailability and Intrusion Detection System if they don't need thesefeatures of the gold service level, just to get the average responsetime below 3 seconds, if that is an important feature for them. Instead,the enterprise can specify precisely what they want, and the serviceprovider can afford to offer that combination at a reduced price fromthe “gold service level.” The enterprise can get very precise about eachcolumn represented above, so they could request the following forexample:

TABLE 2 according to an embodiment Performance Availability SecurityMaximum Average Overall Service Intrusion number of response servicerecovery Data Detection users time availability time encryption System923 2.5 99.93% 12 hours AES-128 None seconds

Embodiments of the invention as described can enable the serviceprovider to generate the design of and build a system designedspecifically to meet these requirements more easily.

FIGS. 19, 20, Embodiment Showing Adapting Existing Models

FIG. 19 shows another embodiment in which the enterprise interface isused to make alterations to an existing modelled business process. Thiscan occur in a test phase before live deployment, or during the lifetimeof a live deployment for example. The same reference numerals have beenused as those in FIG. 16 where appropriate. The enterprise interface iscoupled to an update part 775 which can be implemented as software aspart of the services provided by the service provider, or can beincorporated in the enterprise interface for example. The update part iscoupled to the model generation part and can cause the model generationpart to make changes to the existing model. The update part can bearranged to cooperate with the model generation part to determineconsequential changes to other layers of the model, such as the softwareapplication components and the design of computing infrastructure. Oncethese have been determined, and have been checked to see if the changesare allowable, the update part can cause the deployment part to causedeployment of the changes, either on a test basis, or as part of a livedeployment.

A monitoring part 785 is shown coupled to the deployed software andcomputing infrastructure of the business process 765, to enablemonitoring of the actual performance of the deployment, and feedback anindication of how well the business process matches the non functionalrequirements for example.

FIG. 20 shows steps of the operation of the embodiment of FIG. 19. Atstep 707 inputs of alterations at a high level such as functional stepsand/or non functional requirements are received from the enterpriseinterface. The interface may be arranged to assist the enterprise withprompts about the existing business process, what may be changed, whatparts are performing according to the non functional requirements andwhat parts are not, for example. At step 717 an adapted model ofsoftware application components is generated, according to the inputs.At step 727, an adapted design of computing infrastructure to implementthe adapted software application components is generated, according tothe inputs and according to the adapted model of the softwareapplication components. The adapted model is deployed at step 737 on theshared infrastructure (or dedicated infrastructure, as desired). Theongoing behaviour and performance of the deployed process is monitoredat step 747. Changes in behaviour are reported to the enterprise usingthe enterprise interface, at a high level, corresponding to thefunctional steps or the non functional requirements for example. Thiscan involve for example correlating a monitoring output of a particularinfrastructure entity or software application component (e,g, that it isoverloaded) with a corresponding functional step that is being carriedout so often as to cause the overloading. It can also involve deducingfrom the monitored parameters how well the operation matches the nonfunctional requirements or translating these parameters into onescomparable to the non functional requirements. Typically the enterprisewill want to continuously adapt the modelled business process to respondto changes in ongoing behaviour such as unexpected increases in demand,or changes in other conditions.

The enterprise interface is a notable feature and can enable theenterprise to submit key requirements for a model of the businessprocesses to the utility service provider. When the enterprise desiresto change their business processes, they need only change the high levelparts of the model of the business process, such as the functionalsteps, or non functional requirements. The utility service providerhandles the implementation of the changes to the software applicationcomponents and the computing infrastructure design.

A notable advantage is that this is a much higher-level enterpriseinterface to a utility services provider than is available today, whichcan save the enterprise a lot of time and money and allow them torespond to changing business conditions more rapidly than theircompetitors. Typically, only a few hours will be needed to bring up thecomplete set of applications and supporting IT infrastructure after theenterprise submits the changes, compared to typical delays of days oreven months with traditional methods which are available today.

Another advantage is that because all of the non-functional requirementsand service levels that the enterprise cares about are specified in themodel, the enterprise can for the first time compare prices amongcompeting utility services providers and pick the least expensive one.Today, this is not possible because no utility service providers allowthe enterprise to specify independent values for all of thenon-functional requirements, so enterprises must compare differentlevels of availability, performance, security, etc. among the differentservice providers and pick the best fit. This new interface allows theenterprise to specify the precise fit they require. It can also enablethe enterprise to specify a total budget, and get the most they canwithin that budget.

For the utility service provider it means they can offer better morecustomised service to the enterprise, to allow the enterprise to choosea better trade off of cost, security, performance, availability,reliability, etc. For example, the enterprise could specify how valuablevarious levels of security, performance, availability, and reliabilityare to them, and the utility services provider could give the enterpriseseveral options from which to choose at different prices, or evenoptimize among those various options within the enterprise's budgetenvelope.

Because the Service Level Agreements may also be specified, the utilityservice provider knows exactly what expectations the enterprise has, andexactly what the penalites, credits, or other remediations are for notmeeting each of the expectations. Because the requirements submitted bythe customer are placed into a machine-interpretable model, the buildingand operation of the service can be performed automatically by softwarecomponents.

FIGS. 21 to 25, Embodiments Showing Simulating Operation and TestDeployments

FIG. 21 shows another embodiment having a model store 720. A candidatemodel 740 of a business process is stored there, and has a number ofconstituents. Functional steps 750 are shown, and non functionalrequirements 760, which could be stored external to the model. A modelof software entities 770 for implementing the functional steps, and amodel of computing infrastructure 780 for running the software entitiesare shown. A number of such candidate models, each for differentimplementations of the same business process, are shown. A simulator 730is provided which takes estimated performance parameters 715, andcalculates behaviour and performance of each model. The behaviour andperformance can be compared to the non functional requirements and anevaluation of how well each model meets these requirements can beproduced. This can be used by a model manager 790 to take appropriateaction such as amending the models or selecting which of the candidatesto deploy under test conditions or live production conditions forexample. Deployed software 700 and a deployed design of infrastructure710 are shown.

FIG. 22 shows some of the steps carried out by an embodiment such as theembodiment of FIG. 21. A candidate model is generated in a preliminarystep 870, representing a deployment of a business process. At step 880,the simulator simulates the operation of the model as if it weredeployed. There are various ways of implementing this step. Test inputstypically need to be generated. Performance parameters for each softwareentity and the infrastructure used to run the software according to themodel, may be based on measurements or estimates. At step 890, thesimulated operation is evaluated against the non functional requirementsof the business process. This may involve evaluating simulatedperformance at the business step level, or at other levels, depending onthe non functional requirements. This may involve evaluating how wellother non-functional requirements, for example availability or security,would be met by the candidate model. This is made possible by the modelhaving a representation of not only the software entities but also theunderlying computing infrastructure used to run the software. How wellthe simulated operation meets the non functional requirements can be fedback to the enterprise interface at step 896.

At step 897, further action may be taken depending on the outcome of theevaluation, such as selecting which candidate model to deploy, or otheraction such as changing requirements and generating one or more newcandidate models.

FIG. 23 shows another embodiment. In this case, the model manager 790 isused to manage test deployments. 820 is a test deployment of softwareentities and 830 is a test deployment of computing infrastructure foruse in running the software entities 820. Both are set up by the modelmanager based on a candidate model in the model store. A number ofdifferent candidate models may be deployed in this way eithersimultaneously or at different times. The model manager manages testinputs to the test deployment, and receives measurements fromappropriate monitoring points set up in the software or the computinginfrastructure. This enables the various test deployments to beevaluated against the non functional requirements and enables the modelmanager to make changes or generate new models based on themeasurements, to reach a better implementation.

FIG. 24 shows steps according to another embodiment. In this case,multiple different candidate models representing different ways ofdeploying the same business process are deployed at step 902. Testinputs are applied at step 922. Measurements are made of the outputs andof selected components of these test deployments at step 932. These areused to evaluate the operation of the different test deployments, to seehow well they meet the non functional requirements of the businessprocess, at step 942. How well the operation of the differentdeployments meets the non functional requirements can be fed back to theenterprise interface at step 915.

At step 952, the results of the evaluation can be used to takeappropriate action, such as for example to select a candidate model, orgenerate a new one, on the basis of simulations and test deployments.

FIG. 25 shows another embodiment. In this case, a development process byan operator or developer is shown to refine a grounded model using atemplate. More details of examples of grounded models and templates willbe discussed below with reference to FIG. 1 onwards. A candidate modelis generated at step 926. It is deployed or its operation is simulatedat step 986. Its performance is evaluated at step 996, and at step 998,the remaining parameters are adapted as allowed by the template. Thisadaptation is fed back to step 926. Step 926 involves a number of substeps as follows. Step 936 shows choosing a general process model (GP)from a catalogue by an operator. This is a high level model only. It iscustomized at step 946 to complete the required functional steps withoutnon functional requirements. At step 956 non-functional requirements areinput by the operator. A template for the design of the computinginfrastructure is selected at step 966. This may be done by the operatorwith automated guidance from the model manager which may assess theoptions and show a ranking of the best options. The remaining parametersleft open by the template are then selected at step 976 by the operatoragain optionally with automated guidance from the model manager showinga ranking of the best options. The feedback from the evaluation of thelast iteration can be added to this step 976, to speed up thedevelopment process.

Other Additions or Variations to FIG. 21:

The model-based approach shown in FIG. 21 can be modelled with 4interconnected layers:

-   -   Physical Infrastructure    -   Virtual Infrastructure    -   Software Landscape    -   Business Processes

Physical infrastructure and Virtual infrastructure can be regarded assubsets of computing infrastructure. In one variation to the arrangementof FIG. 21, the model manager can be part of a model based designservice MBDS having a model store 720 which has a number of candidatemodels of the same business process. Each candidate model comprises submodels corresponding to the four layers of the enterprise application.At each layer, the models can in some embodiments consist of both aStatic Model and an Operational Model. The Static Model describes thestatic structure of the system—the selection and configuration optionsof candidate designs of the enterprise application. Additionally, themodel can include detailed Operational Models of the internal structure,run-time operation, and performance demands (such as CPU, memory, disk,or network I/O) of the infrastructure and software. It is theseOperational Models that allow the Simulator to evaluate how well acandidate design will meet the non-functional requirements of theSystem.

An enterprise application can typically consist of multiple DeploymentModules, corresponding to deployable, distributable consistent sub-setsof the complete functionality of the deployed software. These deploymentmodules would form part of the Software Landscape Model. A key decisionof the Design and modelling process is how to carve up the Applicationinto these distributed parts and where to locate the Deployment Modules.

There are functional and non functional requirements for the Enterpriseapplication, entered by an operator or obtained from a store. Amonitoring part can measure behaviour and/or performance of some or allof the layers of the Enterprise application when deployed. The MBDS hasa simulator part and a model simulation manager. An evaluation part forevaluating the simulation results can be a separate part or incorporatedin either the manager or the simulator.

There can also be automated deployment services and a resource pool ofphysical infrastructure, on which the Enterprise application and atleast some of the monitoring part will be deployed. Optionally the MBDScan also use the same physical infrastructure, or it can have its owndedicated physical infrastructure.

Some of the main steps of such a system are as follows:

-   -   0. The functional and non-functional requirements of the        Enterprise System are submitted to the MBDS. The MBDS is also        given the number and types of currently available physical and        virtual resources in the Resource Pool.    -   1. The MBDS creates a population of candidate models in the        Model Pool that may meet the set of requirements. Each model has        different values for the various selection, configuration, and        operational parameters. The generation of initial candidate        models may be driven from templates that describe the best        practise design patterns for the Enterprise System.    -   2. The Simulator uses the Operational Model to simulate and        evaluate each of the models in the Model Pool against the        requirements, and the Model Simulation Manager selects the most        appropriate.    -   3. The selected model, embodying the design of the System, is        submitted to a set of Automated Deployment Services.    -   4. The Automated Deployment Services acquire, create, and        configure the infrastructure, monitoring, and software specified        in the design model.    -   5. Monitored values from the miming system for each of the 4        layers, and/or modifications to the requirements, is fed back to        the MBDS. The Model Simulation Manager is able to compare the        measured values with those predicted by the simulation.    -   6. If the discrepancy between the predicted and measured values        exceeds a threshold, the Model Simulation Manager can either        select a different Model from the pool, or cause new models to        be created in the Model Pool with updated parameters in the        Operational Model, to better predict the behaviour of the        system. Additionally, if the requirements have changed then a        new model can be selected or a new set of candidate models        generated. A new selected model may be given to the Automated        Deployment Services to cause the corresponding changes to be        applied to the miming System.

Various mechanisms can be used for the creation, modification, andselection of models in the Model Pool:

-   -   Many models can be managed in the Model Pool, each of which is        simulated and evaluated against the requirements. The models in        the Model Pool form a candidate population set.    -   Models can be randomly mutated to vary the parameters of        selection, configuration, and evaluation parameters. The degree        and rate of modification may be affected by the discrepancy with        the measured results.    -   Models can be categorised into related sets to create clusters        of models, based on criteria such as giving similar results.        Various heuristics and selection criteria can be applied to        these clusters. For example, if many models in a cluster predict        similar results, then this may be used as a way to increase the        confidence in the predictions of those models.    -   The sensitivity of the predicted behaviour of the system to the        model parameters may be used to drive the degree and rate of        modification of model parameters.    -   Optimise the internal parameters of the Operational Model to        improve the predictability and confidence of the models. This is        achieved by comparison of predicted results with measured values        and analysis of the sensitivity of model parameters.    -   The predicted system behaviour of candidate models, together        with the associated selection and configuration parameters may        be visualised and presented to human experts, who can then not        only make selections of candidate designs but also direct the        model mutation process. The scheme described above for a single        enterprise application A can be applied, largely independently,        to any number of additional services, all of which would run on        the same shared Resource Pool.

Obviously, the interactions and resource contention caused by EnterpriseServices running on the same physical machines would be taken intoaccount in the multi-service scenario.

A key feature of some embodiments of the invention is the application ofthese techniques to an integrated set of models for an EnterpriseSystem, in which the System is modelled at each of the 4 layersdescribed. The integrated approach of the embodiments described canaddress the resource selection, requirements satisfaction, andconfiguration optimisation problems inherent in the design of suchEnterprise Systems.

Model-Based technologies to automatically design and manage EnterpriseSystems—see “Adaptive Infrastructure meets Adaptive Applications”, byBrand et al, published as an external HP Labs Tech Report:

http://www.hpl.hp.com/techreports/2007/HPL-2007-138.htmland incorporated herein by reference, can provide the capability toautomatically design, deploy, modify, monitor, and manage a runningSystem to implement a business process, while minimizing the requirementfor human involvement. The models can have concepts, such as BusinessProcess, Business Process Steps, Business Object, and SoftwareComponent, together with the relationships between them.

The models should not be confused with the source content of thesoftware of an enterprise application. There can be various kinds ofSource Content. Typically the Source Content is owned by the enterpriseapplication Vendor. There may be several forms of Source Content suchas:

-   -   Program Code written in languages such as Java, or ABAP. This        code may be created directly by humans, or automatically        generated from other Program Models or tools.    -   Program Models describe an aspect of the system, such as its        static structure, or run-time behaviour. Program Models are        themselves expressed in some form of mark-up language, such as        XML. Examples might be:    -   State and Action diagrams for the behaviour of software        components.    -   Business Process diagrams describing the set of business process        steps.    -   Structure diagrams describing the static packaging of the        software into deployable units, executables and products.

Program Code or Program Models may be generated via tools, such asgraphical editors, or directly by humans. The syntax and language usedto describe Source Content may vary widely.

More details of an example of using a series of models for such purposeswill now be described. If starting from scratch, a business process isdesigned using a business process modelling tool. The business processis selected from a catalog of available business processes and iscustomized by the business process modeling tool. An available businessprocess is one that can be built and run. There will be correspondingtemplates for these as described below. Then non-functionalcharacteristics such as reliability and performance requirements arespecified.

Next the software entities such as products and components required toimplement the business process are selected. This is done typically bysearching through a catalog of product models in which the model foreach product specifies what business process is implemented. This modelis provided by an application expert or the product vendor.

Next the computing infrastructure such as virtual machines, operatingsystems, and underlying hardware, is designed. This can use templates asdescribed in more detail below, and in above referenced previously filedapplication Ser. No. 11/741,878 “Using templates in automatedmodel-based system design” incorporated herein by reference. A templateis a model that has parameters and options, by filling in the parametersand selecting options a design tool transforms the template into acomplete model of a deployable system. This application shows a methodof modelling a business process having a number of computer implementedsteps using software application components, to enable automaticdeployment on a computing infrastructure, the method having the stepsof:

automatically deriving a grounded model of the business process from anunbound model of the business process, the unbound model specifying theapplication components to be used for each of the computer implementedsteps of the business process, without a complete design of thecomputing infrastructure, and the grounded model specifying a completedesign of the computing infrastructure suitable for automatic deploymentof the business process,the deriving of the grounded model having the steps of providing aninfrastructure design template having predetermined parts of thecomputing infrastructure, predetermined relationships between the parts,and having a limited number of options to be completed, generating acandidate grounded model by generating a completed candidateinfrastructure design based on the infrastructure design template, andgenerating a candidate configuration of the software applicationcomponents used by the unbound model, and evaluating the candidategrounded model, to determine if it can be used as the grounded model.

Next the physical resources from the shared resource pool in the datacenter are identified and allocated. Finally the physical resources areconfigured and deployed and ongoing management of the system can becarried out.

All of this can use SAP R/3 as an example, but is also applicable toother SAP systems or non-SAP systems. Templates as described below caninclude not only the components needed to implement the business processand the management components required to manage that business process,but also designs for computing infrastructure.

The model generation part can be implemented in various ways. One way isbased on a six stage model flow called the Model Information Flow (MIF).This involves the model being developed in stages or phases whichcapture the lifecycle of the process from business requirements all theway to a complete running system. The six phases are shown in FIG. 4described below and each has a corresponding type of model which can besummarised as follows:

-   -   General Model: The starting point, for example a high level        description of business steps based on “out-of-the-box”        functionalities of software packages the user can choose from,        and the generic business processes and their constituent        business process steps.    -   Custom Process Model: defined above and for example a        specialization of the previous model (General Model) with        choices made by the enterprise. This model captures        non-functional requirements such as response time, throughput        and levels of security. Additionally, it can specify        modifications to the generic business processes for the        enterprise.    -   Unbound Model: defined above, and for example an abstract        logical description of the structure and behaviour of a system        capable of running the business process with the requirements as        specified by the enterprise.    -   Grounded Model: defined above and for example can be a        transformation of the previous model (Unbound Model) to specify        infrastructure choices, such as the quantities and types of        hardware and virtualization techniques to use, and also the        structure and configuration of the software to run the business        process.    -   Bound Model: a grounded model for which resources in the data        centre have been reserved.    -   Deployed Model: a grounded model where the infrastructure and        the software components have been deployed and configured. At        this point, the service is up and running.

Each stage of the flow has corresponding types of models which arestored in a Model Repository. Management services consume the modelsprovided by the Model Repository and execute management actions torealize the transitions between phases, to generate the next model inthe MIF. Those services can be for example:

-   -   Template-based Design Service (TDS) (and an example of a model        based design service): translates non-functional requirements        into design choices for a Grounded Model based on the template.    -   Resource Acquisition Service (RAS): its purpose is to allocate        physical resources prior to the deployment of virtual resources,        such as vms.    -   Resource Configuration Service (RCS): its role is to        create/update the virtual and physical infrastructure.    -   Software Deployment Service (SDS): installs and configures the        applications needed to run the business processes and        potentially other software.    -   Monitoring Services (MS) deploys Probes to monitor behaviour of        a Deployed Model. This can include monitoring at any one or more        of these three levels:        -   Infrastructure: e.g. to monitor CPU, RAM, network I/O usage            regardless of which application or functional step is            executing.        -   Application: e.g. to monitor time taken or CPU consumption            of a given application such as a DB process on the operating            system, regardless of which particular infrastructure            component is used.        -   Business process: e.g. count the number of sales order per            hour, regardless of which infrastructure components or            applications are used.

Templates for the Computing Infrastructure Design

Templates are used to capture designs that are known to instantiatesuccessfully (using the management services mentioned above). An exampletemplate describes a SAP module running on a Linux virtual machine (vm)with a certain amount of memory. The templates also capture managementoperations that it is known can be executed, for instance migration ofvm of a certain kind, increasing the memory of a vm, deployingadditional application server to respond to high load, etc. . . . If achange management service refers to the templates, then the templatescan be used to restrict the types of change (deltas) that can be appliedto the models.

Templates sometimes have been used in specific tools to restrictchoices. Another approach is to use constraints which provide the tooland user more freedom. In this approach constraints or rules arespecified that the solution must satisfy. One example might be thatthere has to be at least one application server and at least onedatabase in the application configuration. These constraints on theirown do not reduce the complexity sufficiently for typical businessprocesses, because if there are few constraints, then there are a largenumber of possible designs (also called a large solution space). Ifthere are a large number of constraints (needed to characterize asolution), then searching and resolving all the constraints is reallyhard—a huge solution space to explore. Also it will take a long time tofind which of the constraints invalidates a given possible design fromthe large list of constraints.

Templates might also contain instructions for managing change. Forexample they can contain reconfiguration instructions that need to beissued to the application components to add a new virtual machine with anew slave application server.

The deriving of the grounded model can involve specifying all serversneeded for the application components. This is part of the design of theadaptive infrastructure and one of the principal determinants ofperformance of the deployed business process. The template may limit thenumber or type of servers, to reduce the number of options, to reducecomplexity of finding an optimised solution for example.

The deriving of the grounded model from the unbound model can involvespecifying a mapping of each of the application components to a server.This is part of configuring the application components to suit thedesign of adaptive infrastructure. The template may limit the range ofpossible mappings, to reduce the number of options, to reduce complexityfor example.

The deriving of the grounded model can involve specifying aconfiguration of management infrastructure for monitoring of thedeployed business process in use. This monitoring can be at one or moredifferent levels, such as monitoring the software applicationcomponents, or the underlying adaptive infrastructure, such as softwareoperating systems, or processing hardware, storage or communications.

More than one grounded model can be derived, each for deployment of thesame business process at different times. This can enable more efficientuse of resources for business processes which have time varying demandfor those resources for example. Which of the grounded models isdeployed at a given time can be switched over any time duration, such ashourly, daily, nightly, weekly, monthly, seasonally and so on. Theswitching can be at predetermined times, or switching can be arrangedaccording to monitored demand, detected changes in resources such ashardware failures, or any other factor.

Where the computing infrastructure has virtualized entities, thederiving of the grounded model can be arranged to specify one or morevirtualized entities without indicating how the virtualised entities arehosted. It has now been appreciated that the models and the deriving ofthem can be simplified by hiding such hosting, since the hosting caninvolve arbitrary recursion, in the sense of a virtual entity beinghosted by another virtual entity, itself hosted by another virtualentity and so on. The template can specify virtual entities, and mapapplication components to such virtual entities, to limit the number ofoptions to be selected, again to reduce complexity. Such templates willbe simpler if they do not need to specify the hosting of the virtualentities. The hosting can be defined at some time before deployment, bya separate resource allocation service for example.

The grounded model can be converted to a bound model, by reservingresources in the adaptive infrastructure for deploying the bound model.At this point, the amount of resources needed is known, so it can bemore efficient to reserve resources at this time than reserving earlier,though other possibilities can be conceived. If the grounded model isfor a change in an existing deployment, the method can have the step ofdetermining differences to the existing deployed model, and reservingonly the additional resources needed.

The bound model can be deployed by installing and starting theapplication components of the bound model. This enables the businessprocess to be used. If the grounded model is for a change in an existingdeployment, the differences to the existing deployed model can bedetermined, and only the additional application components need beinstalled and started.

Two notable points in the modelling philosophy are the use of templatesto present a finite catalogue of resources that can be instantiated, andnot exposing the hosting relationship for virtualized resources. Eitheror both can help reduce the complexity of the models and thus enablemore efficient processing of the models for deployment or changing afterdeployment.

Some embodiments can use an infrastructure capability model to presentthe possible types of resources that can be provided by a computingfabric. An instance of an infrastructure capability model contains oneinstance for each type of Computer System or Device that can be deployedand configured by the underlying utility computing fabric. Each time theutility deploys and configures one of these types, the configurationwill always be the same. For a Computer System this can mean thefollowing for example.

Same memory, CPU, Operating SystemSame number of NICs with same I/0 capacitySame number of disks with the same characteristics

The templates can map the application components to computers, while therange of both application components and computers is allowed to vary.In addition the templates can also include some or all of the networkdesign, including for example whether firewalls and subnets separate thecomputers in the solution. In embodiments described below in moredetail, the Application Packaging Model together with the Custom ProcessModel show how the various application components can implement thebusiness process, and are packaged within the Grounded Model.

The template selected can also be used to limit changes to the system,such as changes to the business process, changes to the applicationcomponents, or changes to the infrastructure, or consequential changesfrom any of these. This can make the ongoing management of the adaptiveinfrastructure a more tractable computing problem, and therefore allowmore automation and thus reduced costs. In some example templatescertain properties have a range: for example 0 to n, or 2 to n. A changemanagement tool (or wizard, or set of tools or wizards) only allowschanges to be made to the system that are consistent with template. Thetemplate is used by this change management tool to compute the set ofallowable changes; it only permits allowable changes. This can helpavoid the above mentioned difficulties in computing differences betweenmodels of current and next state, if there are no templates to limit theotherwise almost infinite numbers of possible configurations.

Some of the advantages or consequences of these features are as follows:

1. Simplicity: by using templates it becomes computationally tractableto build a linked tool set to integrate business process, applicationand infrastructure design and management through the entire lifecycle ofdesign, deployment and change.2. By limiting the number of possible configurations of the adaptiveinfrastructure, the particular computing problem of having to computethe differences between earlier and later states of complex models iseased or avoided. This can help enable a management system for theadaptive infrastructure which can determine automatically how to evolvethe system from an arbitrary existing state to an arbitrary desiredchanged state. Instead templates fix the set of allowable changes andare used as configuration for a change management tool.3. The template models formally relate the business process, applicationcomponents and infrastructure design. This means that designs, orchanges, to any one of these can be made dependent on the others forexample, so that designs or changes which are inconsistent with theothers are avoided.

FIG. 1 Overview

FIG. 1 shows an overview of infrastructure, applications, and managementtools and models according to an embodiment. Adaptive infrastructure 280is coupled typically over the Internet to customers 290, optionally viaa business process BP call centre 300. A management system 210 has toolsand services for managing design and deployment and ongoing changes todeployed business processes, using a number of models. Also showncoupled to the management system are an infrastructure managementoperator 200, who can control the operation on behalf of the serviceprovider, and the enterprise interface 795 to allow input from theenterprise and feedback to the enterprise. For example as shown, themanagement system has initial design tools 211, design change tools 213,deployment tools 215, and monitoring and management tools 217. These maybe in the form of software tools such as the monitor part, the simulatorand the model manager described above, running on conventionalprocessing hardware, which may be distributed. Examples of initialdesign tools and design change tools are shown by the servicesillustrated in FIG. 5 described below.

A high level schematic view of some of the models are shown, for twobusiness processes: there can be many more. Typically the managementsystem belongs to a service provider, contracted to provide IT servicesto businesses who control their own business processes for theircustomers. A model 230 of business process 1 is used to develop a design250 of software application components. This is used to create aninfrastructure design 270 for running the application components toimplement the business process. This design can then be deployed by themanagement system to run on the actual adaptive infrastructure, where itcan be used for example by customers (290), a call centre (300) andsuppliers (not shown for clarity). Similarly, item 220 shows a model ofa second business process, used to develop a design 240 of softwareapplication components. This is used to create an infrastructure design260 for running the application components to implement the secondbusiness process. This design can then also be deployed by themanagement system to run on the actual adaptive infrastructure.

The adaptive infrastructure can include management infrastructure 283,for coupling to the monitoring and management tools 217 of themanagement system. The models need not be held all together in a singlerepository: in principle they can be stored anywhere.

FIG. 2 Operation

FIG. 2 shows a schematic view of some operation steps by an operator andby the management system, according to an embodiment. Human operatoractions are shown in a left hand column, and actions of the managementsystem are shown in the right hand column. At step 500 the humanoperator designs and inputs a business process (BP). This can be carriedout via the enterprise interface as described above. At step 510 themanagement system creates an unbound model of the BP. At step 520, theoperator selects a template for the design of the computinginfrastructure. This is typically a service provider operator doingthis. At step 530, the system uses the selected template to create agrounded model of the BP from the unbound model and the selectedtemplate. In principle the selection of the template might be automatedor guided by the system. The human operator of the service provider thencauses the grounded model to be deployed, either as a live businessprocess with real customers, or as a test deployment under controlled orsimulated conditions. The suitability of the grounded model can beevaluated before being deployed as a live business process: an exampleof how to do this is described below with reference to FIG. 3.

At step 550, the system deploys the grounded model of the BP in theadaptive infrastructure. The deployed BP is monitored by a monitoringmeans of any type, and monitoring results are passed to the humanoperator. Following review of the monitoring results at step 570, theoperator of the enterprise can design changes to the BP or the operatorof the service provider can design changes to the infrastructure at step575. These are input to the system, and at step 580 the system decidesif changes are allowed by the same template. If no, at step 585, theoperator decides either for a new template, involving a return to step520, or for a redesign within the limitations of the same template,involving at step 587 the system creating a grounded model of thechanges, based on the same template.

At step 590 the operator of the service provider causes deployment ofthe grounded model for test or live deployment. At step 595 the systemdeploys the grounded model of the changes. In principle the changescould be derived later, by generating a complete grounded model, andlater determining the differences, but this is likely to be moredifficult.

FIG. 3 Operation

FIG. 3 shows an overview of an embodiment showing some of the steps andmodels involved in taking a business process to automated deployment.These steps can be carried out by the management system of FIG. 1, orcan be used in other embodiments.

A business process model 15 has a specification of steps 1-N. There canbe many loops and conditional branches for example as is well known. Itcan be a mixture of human and computer implemented steps, the humaninput being by customers or suppliers or third parties for example. Atstep 65, application components are specified for each of the computerimplemented steps of the business process. At step 75, a complete designof computing infrastructure is specified automatically, based on anunbound model 25. This can involve at step 85 taking an infrastructuredesign template 35, and selecting options allowed by the template tocreate a candidate infrastructure design. This can include design ofsoftware and hardware parts. At step 95, a candidate configuration ofsoftware application components allowed by the template is created, tofit the candidate infrastructure design. Together these form a candidategrounded model.

At step 105, the candidate grounded model is evaluated. If necessary,further candidate grounded models are created and evaluated. Which ofthe candidates is a best fit to the requirements of the business processand the available resources is identified. There are many possible waysof evaluating, and many possible criteria, which can be arranged to suitthe type of business process. The criteria can be incorporated in theunbound model for example.

There can be several grounded models each for different times ordifferent conditions. For example, time varying non-functionalrequirements can lead to different physical resources or even areconfiguration: a VM might have memory, removed out-of-office hoursbecause fewer people will be using it. One might even shutdown anunderused slave application server VM. The different grounded modelswould usually but not necessarily come from the same template withdifferent parameters being applied to generate the different groundedmodels.

The template, grounded and subsequent models can contain configurationinformation for management infrastructure and instructions for themanagement infrastructure, for monitoring the business process whendeployed. An example is placing monitors in each newly deployed virtualmachine which raise alarms when the CPU utilization rises above acertain level—e.g. 60%.

FIG. 4 MIF

FIG. 4 shows some of the principal elements of the MIF involved in thetransition from a custom model to a deployed instance. For simplicity,it does not show the many cycles and iterations that would be involvedin a typical application lifecycle—these can be assumed. The generalmodel 15 of the business process is the starting point and it is assumedthat a customer or consultant has designed a customized businessprocess. That can be represented in various ways, so a preliminary stepin many embodiments is customising it. A custom model 18 is acustomization of a general model. So it is likely that a General Modelcould be modelled using techniques similar to the ones demonstrated formodelling the Custom Model: there would be different business processsteps. A custom model differs from the general model in the followingrespects. It will include non-functional requirements such as number ofusers, response time, security and availability requirements. Inaddition it can optionally involve rearranging the business processsteps: new branches, new loops, new steps, different/replacement steps,steps involving legacy or external systems.

The custom model is converted to an unbound model 25 with inputs such asapplication performance 31, application packaging 21, and applicationconstraints 27. The unbound model can specify at least the applicationcomponents to be used for each of the computer implemented steps of thebusiness process, without a complete design of the computinginfrastructure. The unbound model is converted to a grounded model 55with input from models of infrastructure capability 33, and aninfrastructure design template 35.

Deployment of the grounded model can involve conversion to a bound model57, then conversion of the bound model to a deployed model 63. The boundmodel can have resources reserved, and the deployed model involves theapplications being installed and started.

FIG. 5 MIF

FIG. 5 shows a sequence of steps and models according to anotherembodiment. This shows a model repository 310 which can have models suchas templates (TMP), an unbound model (UM), a bound model (BM), apartially deployed model (PDM), a fully deployed model (FDM). The figurealso shows various services such as a service 320 for generating agrounded model from an unbound model using a template. Another serviceis a resource acquisition service 330 for reserving resources using aresource directory 340, to create a bound model.

An adaptive infrastructure management service 350 can configure andignite virtual machines in the adaptive infrastructure 280, according tothe bound model, to create a partially deployed model. Finally asoftware deployment service 360 can be used to take a partially deployedmodel and install and start application components to start the businessprocess, and create a fully deployed model.

FIG. 6 Deriving Grounded Model

FIG. 6 shows steps in deriving a grounded model according to anembodiment. At step 400, a template is selected from examples such ascentralised or decentralised arrangements. A centralised arrangementimplies all is hosted on a single server or virtual server. Othertemplate choices may be for example high or low security, depending forexample on what firewalls or other security features are provided. Othertemplate choices may be for example high or low availability, which canimply redundancy being provided for some or all parts.

At step 410, remaining options in the selected template are filled in.This can involve selecting for example disk sizes, numbers of dialogprocesses, number of servers, server memory, network bandwidth, databasetime allowed and so on. At step 420, a candidate grounded model iscreated by the selections. Step 430 involves evaluating the candidategrounded model e.g. by building a queuing network, with resourcesrepresented, and with sync points representing processing delays, dbdelays and so on. Alternatively the evaluation can involve deploying themodel in an isolated network with simulated inputs and conditions.

At step 440, the evaluation or simulation results are compared withgoals for the unbound model. These can be performance goals such asmaximum number of simultaneous users with a given response time, ormaximum response time, for a given number of users. At step 450, anothercandidate grounded model can be created and tested with differentoptions allowed by the template. At step 460 the process is repeated forone or more different templates. At step 470, results are compared toidentify which candidate or candidates provides the best fit. More thanone grounded model may be selected, if for example the goals orrequirements are different at different times for example. In this case,the second or subsequent grounded model can be created in the form ofchanges to the first grounded model.

FIG. 7 Master and Slave Application Servers

FIG. 7 shows an arrangement of master and slave application servers fora decentralised or distributed design of computing infrastructure,according to an embodiment. A master application server 50 is providedcoupled by a network to a database 60, and to a number of slaveapplication servers 70. Some slaves can be implemented as slaveapplication servers 72. Each slave can have a number of dialog workerprocesses 80. The master application server is also coupled to remoteusers using client software 10. These can each have a graphical userinterface GUI on a desktop PC 20 coupled over the internet for example.The slaves can be used directly by the clients once the clients havelogged on using the master.

FIG. 8 Master Application Server

FIG. 8 shows parts of a master application server for the embodiment ofFIG. 7. An enqueue process 110 is provided to manage locks on thedatabase. A message server 120 is provided to manage login of users andassignment of users to slave application servers for example. An updateserver 130 is provided for managing committing work to persistentstorage in a database. A print server 140 can be provided if needed. Aspool server 150 can be provided to run batch tasks such as reports. At160 dialog worker processes are shown for running instances of theapplication components.

FIG. 9 Virtual Entities

FIG. 9 shows an arrangement of virtual entities on a server, for use inan embodiment. A hierarchy of virtual entities is shown. At an operatingsystem level there are many virtual machines VM. Some are hosted onother VMs. Some are hosted on virtual partitions VPARs 610 representinga reconfigurable partition of a hardware processing entity, for exampleby time sharing or by parallel processing circuitry. A number of thesemay be hosted by a hard partitioned entity nPAR 620 representing forexample a circuit board mounting a number of the hardware processingentities. Multiple nPARs make up a physical computer 630 which istypically coupled to a network by network interface 650, and coupled tostorage such as via a storage area network SAN interface 640.

There are many commercial storage virtualization products on the marketfrom HP, IBM, EMC and others. These products are focused on managing thestorage available to physical machines and increasing the utilization ofstorage. Virtual machine technology is a known mechanism to runoperating system instances on one physical machine independently ofother operating system instances. It is known, within a single physicalmachine, to have two virtual machines connected by a virtual network onthis machine. VMware is a known example of virtual machine technology,and can provide isolated environments for different operating systeminstances running on the same physical machine.

There are also many levels at which virtualization can occur. Forexample HP's cellular architecture allows a single physical computer tobe divided into a number of hard partitions or nPARs. Each nPAR appearsto the operating system and applications as a separate physical machine.Similarly each nPAR can be divided into a number of virtual parititionsor vPARs and each vPAR can be divided into a number of virtual machines(e.g. HPVM, Xen, VMware).

FIGS. 10 to 15

The next part of this document describes in more detail with referenceto FIGS. 10 to 15 examples of models that can be used within the ModelInformation Flow (MIF) shown in FIGS. 1 to 9, particularly FIG. 4. Thesemodels can be used to manage an SAP application or other businessprocess through its entire lifecycle within a utility infrastructure.The diagrams are shown using the well known UML (Unified ModellingLanguage) that uses a CIM (common information model) style. Theimplementation can be in Java or other software languages.

A custom model can have a 1-1 correspondence between an instance of anAIService and a BusinessProcess. The AIService is the informationservice that implements the business process.

-   -   A business process can be decomposed into a number of business        process steps (BPsteps), so instances of a BusinessProcess class        can contain 1 or more BPSteps. An instance of a BPStep may be        broken into multiple smaller BPSteps involving sequences,        branches, recursions, and loops for example. Once the        BusinessProcess step is decomposed into sufficient detail, each        of the lowest level BPSteps can be matched to an        ApplicationComponent. An ApplicationComponent is the program or        function that implements the BPStep. For SAP, an example would        be the SAP transaction named VA01 in the SD (Sales and        Distribution package) of SAP R/3 Enterprise. Another example        could be a specific Web Service (running in an Application        Server).

BPStep can have stepType and stepParams fields to describe not onlyexecution and branching concepts like higher-level sequences of steps,but also the steps themselves. The stepType field is used to definesequential or parallel execution, loops, and if-then-else statements.The stepParams field is used to define associated data. For example, inthe case of a loop, the stepParams field can be the loop count or atermination criterion. The set of BPSteps essentially describes a graphof steps with various controls such as loops, if-then-else statements,branching probabilities, etc.

The relation BPStepsToApplicationComponentMapping is a complex mappingthat details how the BPStep is mapped to the ApplicationComponent. Itrepresents, in a condensed form, a potentially complex mix ofinvocations on an Application Component by the BPStep, such as thespecific dialog steps or functions invoked within theApplicationComponent or set of method calls on a Web Service, andprovided details of parameters, such as the average number of line itemsin a sales order.

A BPStep may have a set of non-functional requirements(NonFunctionalRequirements) associated with it: performance,availability, security, and others. Availability and securityrequirements could be modelled by a string: “high”, “medium”, “low”.Performance requirements are specified in terms of for example a numberof registered users (NoUsersReq), numbers of concurrent users of thesystem, the response time in seconds and throughput requirement for thenumber of transactions per second. Many BPSteps may share the same setof non-functional requirements. A time function can be denoted by astring. This specifies when the non-functional requirements apply, sodifferent requirements can apply during office-hours to outside ofnormal office hours. Richer time varying functions are also possible tocapture end of months peaks and the like.

FIGS. 10, 11 Custom Model

For an example of a Custom Model the well-known Sales and Distribution(SD) Benchmark will be discussed. This is software produced by the wellknown German company SAP. It is part of the SAP R/3 system, which is acollection of software that performs standard business functions forcorporations, such as manufacturing, accounting, financial management,and human resources. The SAP R/3 system is a client server system ableto run on virtually any hardware/software platform and able to use manydifferent database management systems. For example it can use an IBMAS/400 server running operating system OS/400 using database system DB2;or a Sun Solaris (a dialect of Unix) using an Oracle database system; oran IBM PC running Windows NT using SQL Server.

SAP R/3 is designed to allow customers to choose their own set ofbusiness functions, and to customize to add new database entities or newfunctionality. The SD Benchmark simulates many concurrent users usingthe SD (Sales and Distribution) application to assess the performancecapabilities of hardware. For each user the interaction consists of 16separate steps (Dialog Steps) that are repeated over and over. The stepsand their mapping to SAP transactions are shown in FIG. 10. Atransaction here is an example of an Application Component. Eachtransaction is shown as a number of boxes in a row. A first box in eachrow represents a user invoking the transaction e.g. by typing /nva01 tostart transaction VA01. As shown in FIG. 10, transaction VA01 in the toprow involves the business process steps of invoking the create salesorder transaction, then filling order details, then saving the sold-toparty, and completing with the “back” function F3 which saves the data.

A next transaction VL01N is shown in the second row, and involves stepsas follows to create an outbound delivery. The transaction is invoked,shipping information is filled in, and saved. A next transaction VA03 isshown in the third row for displaying a customer sales order. Thisinvolves invoking the transaction, and filling subsequent documents. Afourth transaction is VL02N in the fourth row, for changing an outbounddelivery. After invoking this transaction, the next box shows saving theoutbound delivery. A next transaction shown in the fifth row is VA05,for listing sales orders. After invoking this transaction, the next boxshows prompting the user to fill in dates and then a third box showslisting sales orders for the given dates. Finally, in a sixth row, thetransaction VF01 is for creating a billing document, and shows filling aform and saving the filled form.

FIG. 11 shows an example of a custom model instance for the SDBenchmark. The top two boxes indicate that the business process“BPModel” contains one top level BPStep: “SD Benchmark”, withstepType=Sequence. Two lines are shown leading from this box, one to thenon-functional requirements associated with this top-level BPStep, andshown by the boxes at the left hand side. In this particular case onlyperformance requirements have been specified—one for 9 am-5 pm and theother for 5 pm-9 am. Other types of non-functional requirements notshown could include security or availability requirements for example.In each case the performance requirements such as number of users,number of concurrent users, response time required, and throughputrequired, can be specified as shown. These are only examples, otherrequirements can be specified to suit the type of business process. Abox representing the respective time function is coupled to eachperformance requirement box as shown. One indicates 9 am to 5 pm, andthe other indicates 5 pm to 9 am in this example.

On the right hand side a line leads from the SD Benchmark BPStep to thefunctional requirements shown as six BPSteps, with stepType=Step—one foreach SAP transaction shown in FIG. 10 (VA01, VL01N, etc). Forconvenience the name of the first dialog step for each transaction shownin FIG. 10 is used as the name of the corresponding BPStep shown in FIG.11 (“Create sales order”, “Create outbound delivery”, “Display customersales order”, “Change outbound delivery”, “List sales order”, and“Create delivery document”). For each of these steps theBPStepToApplicationComponentMapping relation specifies the details ofthe dialog steps involved. For example in the case of CreateSalesOrder,FIG. 10 shows that the BPStepToApplicationComponentMapping needs tospecify the following dialog steps are executed in order: “Create SalesOrder”, “Fill Order Details”, “Sold to Party” and “Back”. In addition itmight specify the number of line items needed for “Fill Order Details”.At the right hand side of the figure, each BP step is coupled to aninstance of its corresponding ApplicationComponent via the respectivemapping. So BPstep “Create Sales order” is coupled toApplicationComponent VA01, via mapping having ID:001. BPstep “Createoutbound delivery” is coupled to ApplicationComponent VL01N via mappinghaving ID:002. BPstep “Display customer sales order” is coupled viamapping having ID:003 to ApplicationComponent VA03. BPstep “Changeoutbound delivery” is coupled via mapping having ID:004 toApplicationComponent VL02N. BPstep “List sales order” is coupled viamapping having ID:005 to ApplicationComponent VA05. BPstep “Createdelivery document” is coupled via mapping having ID:006 toApplicationComponent VF01.

FIG. 12, The Unbound Model

The Unbound Model is used to calculate resource demands. As shown inFIG. 12 this model can be made up of four models: the Custom Model(labelled CustomizedProcessingModel), Application Packaging, ApplicationConstraints and Application Performance models, an example of each ofwhich will be described below (other than the Custom Model, an exampleof which has been described above with respect to FIG. 11). Otherarrangements can be envisaged. No new information is introduced that isnot already contained in these four models.

FIG. 12, Application Packaging Model

The Application Packaging Model describes the internal structure of thesoftware:

what products are needed and what modules are required from the product.An ApplicationComponent can be contained in an ApplicationModule. AnApplicationModule might correspond to a JAR (Java archive) file for anapplication server, or a table in a database. In the case of SAP itmight be the module to be loaded from a specific product into anapplication server such as SD or FI (Financials). The applicationpackaging model can have a DiskFootPrint to indicate the amount of diskstorage required by the ApplicationModule. In the case of theApplicationComponent VA01 in FIG. 10, it is from SD with a DiskFootPrintof 2 MB for example.

One or more ApplicationModules are contained within a product. So forexample SAP R/3 Enterprise contains SD. ApplicationModules can bedependent on other ApplicationModules. For example the SD Code for theApplication Server depends on both the SD Data and the SD Executablecode being loaded into the database. The Application Packaging modelshows an ApplicationExecutionComponent that executes anApplicationComponent. This could be a servlet running in an applicationserver or a web server. It could also be a thread of a specificcomponent or a process. In the case of SD's VA01 transaction it is aDialog Work Process. When it executes, the ApplicationComponent mayindirectly use or invoke other Application-Components to run: a servletmay need to access a database process; SD transactions need to accessother ApplicationComponents such as the Enqueue Work Process and theUpdate Work Process, as well as the DatabaseApplicationExecutionComponent.

The ApplicationExecutionComponent can be contained by and executed inthe context of an ApplicationExecutionService (SAP application server)which loads or contains ApplicationModules (SD) and manages theexecution of ApplicationExecutionComponents (Dialog WP) which, in turn,execute the ApplicationComponent (VA01) to deliver a BPStep.

FIG. 12, Application Constraints model

The Application Constraints Model expresses arbitrary constraints oncomponents in the Customized Process, Application Packaging andComponent Performance Models. These constraints are used by tools togenerate additional models as the MIF progresses from left to right.Examples of constraints include:

-   -   How to scale up an application server—what        ApplicationExecutionComponents are replicated and what are not.        For example, to scale up an SAP application server to deal with        more users one cannot simply replicate the first instance—the        master application server 50 of FIGS. 7 and 8, commonly known as        the Central Instance. Instead a subset of the components within        the Central Instance is needed. This is also an example of        design practice: there may be other constraints encoding best        design practice.    -   Installation and configuration information for        ApplicationComponents, ApplicationExecutionComponents and        ApplicationExecutionServices    -   Performance constraints on ApplicationExecutionServices—e.g. do        not run an application server on a machine with greater than 60%        CPU utilization

Other examples of constraints include ordering: the database needs to bestarted before the application server. Further constraints might be usedto encode deployment and configuration information. The constraints canbe contained all in the templates, or provided in addition to thetemplates, to further limit the number of options for the groundedmodel.

FIG. 12, Application Performance Model

The purpose of the Application Performance Model is to define theresource demands for each BPStep. There are two types of resource demandto consider.

-   -   1. The demand for resources generated directly by the        ApplicationExecutionComponent (e.g. Dialog WP) using CPU,        storage I/O, network I/O and memory when it executes the BPStep        —the ComponentResourceDemand    -   2. The demand for resources generated by components that the        above ApplicationExecutionComponent causes when it uses, calls        or invokes other components (e.g. a Dialog WP using an Update        WP)—the IndirectComponentResourceDemand

The IndirectComponentResourceDemand is recursive. So there will be atree like a call-graph or activity-graph.

A complete Application Performance Model would contain similarinformation for all the BPSteps shown in FIG. 11. For example the set ofdialog steps in the BPStep “Create Sales Order” might consume 0.2 SAPS.Further it consists of 4 separate invocations (or in SAP terminologyDialog Steps). The calls are synchronous.

The following are some examples of attributes that can appear inIndirectComponentResourceDemands and ComponentResourceDemands.

-   -   delayProperties: Any delay (e.g. wait or sleep) associated with        the component's activity which does not consume any CPU,        NetIOProperties and DiskIOProperties.    -   NumInvocation: The number of times the component is called        during the execution of the BPStep.    -   —InvocationType: synchronous if the caller is blocked;        asynchronous if the caller can immediately continue activity.    -   BPStepToAppCompID: This is the ID attribute of the        BPStepToApplicationComponentMapping. The reason for this is that        a particular ApplicationExecutionComponent is likely to be        involved in several different BPSteps.    -   ApplicationEntryPoint: This is the program or function being        executed. In the case of “Create Sales Order” this is VA01 for        the DialogWP. It could also be a method of a Web Service.

CPUProperties can be expressed in SAPs or in other units. There arevarious ways to express MemProperties, NetIOProperties andDisklIOProperties.

FIG. 12, Component Performance Model

There is one instance of an Application Performance Model for eachinstance of a Custom Model. This is because, in the general case, eachbusiness process will have unique characteristics: a unique ordering ofBPSteps and/or a unique set of data characteristics for each BPStep. TheDirectComponentResourceDemands and IndirectComponentResourceDemandsassociations specify the unique resource demands for each BPStep. Thesedemands need to be calculated from known characteristics of eachApplicationComponent derived from benchmarks and also traces ofinstalled systems.

The Component Performance Model contains known performancecharacteristics of each ApplicationComponent. A specific ApplicationPerformance Model is calculated by combining the following:

-   -   The information contained in the        BPStepToApplicationComponentMapping associations in the Custom        Model    -   Any performance related constraints in the Application        Constraints Model    -   Component Performance Model

Taken together, the models of the Unbound Model specify not only thenon-functional requirements of a system, but also a recipe for how togenerate and evaluate possible software and hardware configurations thatmeet those requirements. The generation of possible hardwareconfigurations is constrained by the choice of infrastructure availablefrom a specific Infrastructure Provider, using information in anInfrastructure Capability Model, and by the selected template.

A general principle that applies to deployable software elementsdescribed in the Unbound Model, such as theApplicationExecutionComponent or ApplicationExecutionService, is thatthe model contains only the minimum number of instances of each type ofelement necessary to describe the structure of the application topology.For example, in the case of SD only a single instance of a Dialog WorkProcess ApplicationExecutionComponent associated with a single instanceof an Application Server ApplicationExecutionService is needed in theUnbound Model to describe the myriad of possible ways of instantiatingthe grounded equivalents of both elements in the Grounded Model. It isthe template and packaging information that determines exactly how theseentities can be replicated and co-located.

The Infrastructure Capability Model

As discussed above, two notable features of the modelling philosophydescribed are:

1. Present a template having a finite catalogue of resources that can beinstantiated, so that there are a fixed and finite number of choices.For example, small-xen-vm 1-disk, medium-xen-vm 2-disk, large-xen-vm3-disk, physical-hpux-machine etc. This makes the selection of resourcetype by any capacity planning tool simpler. It also makes theinfrastructure management easier as there is less complexity in resourceconfiguration—standard templates can be used.2. Do not expose the hosting relationship for virtualized resources. TheDMTF Virtualization System Profile models hosting relationship as a“HostedDependency” association. This does not seem to be required ifthere is only a need to model a finite number of resource types, so itdoes not appear in any of the models discussed here. This keeps themodels simpler since there is no need to deal with arbitrary recursion.It does not mean that tools that process these models can't use the DMTFapproach internally if that is convenient. It may well be convenient fora Resource Directory Service and Resource Assignment Service to use thisrelationship in their internal models.

An instance of an infrastructure capability model contains one instancefor each type of ComputerSystem or Device that can be deployed andconfigured by the underlying utility computing fabric. Each time theutility deploys and configures one of these types the configuration willalways be the same. For a ComputerSystem this means the following.

-   -   Same memory, CPU, Operating System    -   Same number of NICs with same I/O capacity    -   Same number of disks with the same characteristics

FIG. 13 Template Example

FIG. 13 shows an example of an infrastructure design template havingpredetermined parts of the computing infrastructure, predeterminedrelationships between the parts, and having a limited number of optionsto be completed. In this case it is suitable for a decentralised SDbusiness process, without security or availability features. The figureshows three computer systems coupled by a network labelled “AI_network”,the right hand of the three systems corresponding to a masterapplication server, and the central one corresponds to slave applicationservers as shown in FIG. 7. Hence it is decentralized. AI is anabbreviation of Adaptive Infrastructure. The left hand one of thecomputer systems is for a database. The type of each computer system isspecified, in this case as a BL20/Xen. The central one, corresponding toslave application servers has an attribute “range=0 . . . n”. This meansthe template allows any number of these slave application servers.

The master application server is coupled to a box labelledAI_GroundedExecutionService:AppServer, indicating it can be used to runsuch a software element. It has an associated AIDeploymentSetting boxwhich contains configuration information and deployment informationsufficient to allow the AI_GroundedExecutionService to be automaticallyinstalled, deployed and managed. TheAI_GroundedExecutionService:AppServer is shown as containing threecomponents, labelled AI_GroundedExecutionComponents, and each having anassociated AIDeploymentSetting box. A first of these components is adialog work process, for executing the application components of stepsof the business process, another is an update process, responsible forcommitting work to persistent storage, and another is an enqueueprocess, for managing locks on a database. As shown, the range attributeis 2 . . . n for the update and the dialog work process, meaningmultiple instances of these parts are allowed.

The slave application server has a GroundedExecutionService having onlyone type of AI_GroundedExecutionComponent for any number of dialog workprocesses. The slave application server is shown having arangePolicy=Time function, meaning it is allowed to be active at giventimes. Again the service and the execution component each have anassociated AIDeploymentSetting box.

The master and slave application servers and the database computersystem have an operating system shown as AI_disk: OSDisk. The masterapplication server is shown with an AI_Disk: CIDisk as storage for useby the application components. For the network, each computer system hasa network interface shown as AI_Nic1, coupled to the network shown byAI_Network:subnet1

The database computer system is coupled to a box labelledAI_GroundedExecutionService: Database, which has only one type ofAI_GroundedExecutionComponent, SD DB for the database. Again the serviceand the execution component each have an associated AIDeploymentSettingbox. A/DeploymentSetting carries the configuration and managementinformation used to deploy, configure, start, manage and change thecomponent. Further details of an example of this are described belowwith reference to FIG. 14. This computer system is coupled to storagefor the database labelled AI_Disk: DBDisk.

Optionally the template can have commands to be invoked by the tools,when generating the grounded model, or generating a changed groundedmodel to change an existing grounded model. Such commands can bearranged to limit the options available, and can use as inputs, parts ofthe template specifying some of the infrastructure design. They can alsouse parts of the unbound model as inputs.

FIG. 14 Grounded Model

The Grounded Model may be generated by a design tool as it transformsthe Unbound Model into the Grounded Model. It can be regarded as acandidate Grounded Model until evaluated and selected as the chosenGrounded Model. The following are some of the characteristics of theexample Grounded Model of FIG. 14 compared to the template shown in FIG.13, from which it is derived.

-   -   The number of instances of GroundedExecutionComponent has been        specified.    -   The GroundedExecutionComponents are executed by a        GroundedExecutionService. The execution relationship is        consistent with that expressed in the Application Packaging        Model.    -   The GroundedExecutionServices are run on a ComputerSystem whose        type has been selected from the Infrastructure Capability Model.    -   There are two update components, Update1 and Update2. There are        two DialogWorkProcesses, DialogWorkProcess1 and        DialogWorkProcess2.    -   The number of slave application servers has been set at zero.

The management system is arranged to make these choices to derive theGrounded Model from the template using the Unbound Model. In the exampleshown, the criteria used for the choice includes the total capacity ofthe system, which must satisfy the time varying Performance Requirementsin the Custom Model. The required capacity is determined by combiningthese Performance Requirements with the aggregated ResourceDemands[Direct and Indirect] of the Application Performance Model. If the firstchoice proves to provide too little capacity, or perhaps too much, thenother choices can be made and evaluated. Other examples can havedifferent criteria and different ways of evaluating how close thecandidate grounded model is to being a best fit.

In some examples the server may only have an OS disk attached; that isbecause the convention in such installations is to NFS mount the CI diskto get its SAP executable files. Other example templates could haveselectable details or options such as details of the CIDisk and theDBDisk being 100 GB, 20 MB/sec, non Raid, and so on. The OS disks can beof type EVA800. The master and slave application servers can have 2 to 5dialog work processes. Computer systems are specified as having 3 GBstorage, 2.6 GHz CPUs and SLES 10-Xen operating system for example.Different parameters can be tried to form candidate Grounded Modelswhich can be evaluated to find the best fit for the desired performanceor capacity or other criteria.

The Grounded Model therefore specifies the precise number and types ofrequired instances of software and hardware deployable entities, such asGroundedExecutionComponent, GroundedExecutionService, andAIComputerSystem. AIDeploymentSettings can include for example:

-   -   InfrastructureSettings such as threshold information for        infrastructure management components, for example        MaxCPUUtilization—if it rises above the set figure, say 60%, an        alarm should be triggered.    -   Management policy can specify further policy information for the        management components—e.g. flex up if utilization rises above        60%    -   GroundedDeploymentSettings which can include all command line        and configuration information so that the system can be        installed, configured and started in a fully functional state.    -   SettingData which can provide additional configuration        information that can override information provided in the        GroundedDeploymentSettings. This allows many GroundedComponents        to share the same GroundedDeploymentSettings (c.f. a notion of        typing) with specific parameters or overrides provided by        SettingData. Both the GroundedDeploymentSettings and SettingData        are interpreted by the Deployment Service during deployment.    -   Data related to possible changes to the component such as        instructions to be carried out when managing changes to the        component, to enable more automation of changes.

Not all attributes are set in the Grounded Model. For example, it doesnot make sense to set MAC addresses in the Grounded Model, since thereis not yet any assigned physical resource.

FIG. 15, an Alternative Adaptive Infrastructure Design Template

FIG. 15 shows an alternative adaptive infrastructure design template, ina form suitable for a centralised secure SD business process. Comparedto FIG. 13, this has only one computer system, hence it is centralised.It shows security features in the form of a connection of the network toan external subnet via a firewall. This is shown by an interfaceAI_Nic:nicFW, and a firewall shown by AI_Appliance: FireWall.

Other templates can be envisaged having any configuration. Otherexamples can include a decentralised secure SD template, a decentralisedhighly available SD template, and a decentralised, secure and highlyavailable SD template.

Bound Model

A Bound Model Instance for a SD system example could have in addition tothe physical resource assignment, other parameters set such as subnetmasks and MAC addresses. A Deployed Model could differ from the BoundModel in only one respect. It shows the binding information for themanagement services running in the system. All the entities would havemanagement infrastructure in the form of for example a managementservice. The implementation mechanism used for the interface to themanagement services is not defined here, but could be a reference to aWeb Service or a SmartFrog component for example. The management servicecan be used to change state and observe the current state. Neither thestate information made available by the management service, nor theoperations performed by it, are necessarily defined in the core of themodel, but can be defined in associated models.

One example of this could be to manage a virtual machine migration. Theapplication managing the migration would use the management servicemiming on the PhysicalComputerSystem to do the migration. Once themigration is completed, the management application would update thedeployed model and bound models to show the new physical system. Careneeds to be taken to maintain consistency of models. All previous modelinstances are kept in the model repository, so when the migration iscomplete, there would be a new instance (version) of the bound anddeployed models.

Information Hiding and the Model Information Flow

It is not always the case that for the MIF all tools and every actor cansee all the information in the model. In particular it is not the casefor deployment services having a security model which requires strongseparation between actors. For example, there can be a very strongseparation between a utility management plane and farms of virtualmachines. If a grounded model is fed to the deployment services of themanagement plane by an enterprise to deploy the model, it will notreturn any binding information showing the binding of virtual tophysical machines; that information will be kept inside the managementplane. That means there is no way of telling to what hardware that farmis bound or what two farms might be sharing. What is returned from themanagement plane is likely to include the IP address of the virtualmachines in the farms (it only deals with virtual machines) and thelogin credentials for those machines in a given farm. The managementplane is trusted to manage a farm so that it gets the requestedresources. Once the deployment service has finished working, one coulduse application installation and management services to install, startand manage the applications. In general different tools will seeprojections of the MIF. It is possible to extract from the MIF modelsthe information these tools require and populate the models with theresults the tools return. It will be possible to transform between theMIF models and the data format that the various tools use.

Implementation:

The software parts such as the models, the model repository, and thetools or services for manipulating the models, can be implemented usingany conventional programming language, including languages such as Java,or C compiled following established practice. The servers and networkelements can be implemented using conventional hardware withconventional processors. The processing elements need not be identical,but should be able to communicate with each other, e.g. by exchange ofIP messages.

The foregoing description of embodiments of the invention has beenpresented for purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdisclosed, and modifications and variations are possible in light of theabove teachings or may be acquired from practice of the invention. Theembodiments were chosen and described in order to explain the principlesbehind the invention and its practical applications to enable oneskilled in the art to utilize the invention in various embodiments andwith various modifications as are suited to the particular usecontemplated. Other variations can be conceived within the scope of theclaims.

1. A method of using a modelling system to provide a computer basedbusiness process for an enterprise, so as to enable at least partiallyautomated deployment of the business process, the business processhaving a number of functional steps, the method having the steps of: a)allowing the enterprise to input to the modelling system values for aplurality of non functional requirements for the deployment, so as toprovide freedom for the enterprise to vary at least some of the valuesindependently of others of the values, and b) using the modelling systemto create the model using the values input, by: c) creating in the modela design of software application components for carrying out thefunctional steps, and d) creating in the model a design of computinginfrastructure, for running the software application components, so thatthe business process deployed as set out in the model, operatesaccording to the values input for the non functional requirements of thebusiness process.
 2. The method of claim 1, the input values beingchanges to values of non functional requirements for an existingdeployment, and the step of creating the model comprising making changesto an existing model.
 3. The method of claim 1 having the step ofdeploying the model to operate the business process.
 4. The method ofclaim 1 having the step of using the model to simulate operation, anddetermine how well the simulated operation accords to the non functionalrequirements.
 5. The method of claim 4 having the step of makingavailable to the enterprise an indication of how well the simulatedoperation accords to the non functional requirements.
 6. The method ofclaim 3 having the steps of monitoring the operation of the deployedbusiness process, and of making available to the enterprise anindication of how well the operation accords to the non functionalrequirements based on the monitoring.
 7. The method of claim 1, havingthe step of outputting the design of computing infrastructure, thedesign comprising virtual infrastructure, without a complete mapping tophysical infrastructure, for later deployment by mapping onto physicalinfrastructure.
 8. The method of claim 1, having the step of outputtingthe design of computing infrastructure, the design comprising physicalinfrastructure without virtualisation.
 9. The method of claim 1, havingthe step of outputting the design of computing infrastructure, thedesign comprising both virtual and physical infrastructure, and amapping of the virtual infrastructure onto corresponding physicalinfrastructure.
 10. The method of claim 1, the step of creating in themodel an arrangement of software application components comprisingcreating an unbound model with a representation of software applicationperformance, and software application packaging.
 11. The method of claim10, the step of creating in the model a design of computinginfrastructure comprising creating a grounded model from the unboundmodel, with a representation of infrastructure design and infrastructurecapability.
 12. The method of claim 11, the step of creating the designof computing infrastructure comprising providing an infrastructuredesign template having a limited number of options to be completed. 13.Software on a machine readable medium which when executed carries outthe method of claim
 1. 14. A method having steps by an enterpriseoperator using an interface to a modelling system to provide a computerbased business process for the enterprise, so as to enable at leastpartially automated deployment of the business process, the businessprocess having a number of functional steps, the method having the stepsof: a) inputting values to the modelling system for a plurality of nonfunctional requirements for the deployment, so as to provide freedom forthe enterprise to vary at least some of the values independently ofothers of the values, and b) causing the modelling system to create themodel using the values input, the model having a design of softwareapplication components for carrying out the functional steps, and adesign of computing infrastructure, for running the software applicationcomponents, so that the business process deployed as set out in themodel, operates according to the values input for the non functionalrequirements of the business process, and c) receiving an indication ofhow well the operation of the business process is meeting the nonfunctional requirements, and inputting changed values.
 15. A modellingsystem to provide a computer based business process for an enterprise,so as to enable at least partially automated deployment of the businessprocess, the business process having a number of functional steps, thesystem having: a) an interface to allow the enterprise to input valuesfor a plurality of non functional requirements for the deployment, so asto provide freedom for the enterprise to vary at least some of thevalues independently of others of the values, and b) a model generatingpart coupled to the interface and arranged to create the model using thevalues input, by: c) creating in the model a design of softwareapplication components for carrying out the functional steps, and d)creating in the model a design of computing infrastructure, for runningthe software application components, so that the business processdeployed as set out in the model, operates according to the values inputfor the non functional requirements of the business process.
 16. Thesystem of claim 15, the input values being changes to values of nonfunctional requirements for an existing deployment, and the modelgenerating part being arranged to create the model by making changes toan existing model.
 17. The system of claim 15 having a deployment partfor deploying the model to operate the business process.
 18. The systemof claim 15 having a simulator arranged to use the model to simulateoperation of the business process, and determine how well the simulatedoperation accords to the non functional requirements.
 19. The system ofclaim 18 having the step of making available to the enterprise anindication of how well the simulated operation accords to the nonfunctional requirements.
 20. The system of claim 17 having a monitoringpart arranged to monitor the operation of the deployed business process,and the system being arranged to use the interface to make available tothe enterprise an indication of how well the operation accords to thenon functional requirements based on the monitoring.
 21. The system ofclaim 15, the model generating part being arranged to create an unboundmodel having the design of software application components with arepresentation of software application performance, and softwareapplication packaging.
 22. The system of claim 21, the model generatingpart being arranged to create a grounded model from the unbound model,the design of computing infrastructure and a representation ofinfrastructure design and infrastructure capability.
 23. The system ofclaim 15, the model generator being arranged to create the design ofcomputing infrastructure using an infrastructure design template havinga limited number of options to be completed.